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EXECUTIVE  SUMMARY 


The  SDIO  Panel  on  Computing  in  Support  of  Battle  Management  waa  ap pointed 
“to  devise  an  appropriate  computational/communication  response  to  the  (SDI 
2L«  cPoC;Ul  problem  and  mahe  recommendations  for  a  research  and 
technology  development  program  to  implement  the  response. 

The  oanel  concludes  that  computing  resources  and  battle  management  software 
for  a  stratTg  def  l  system  are  within  the  capabilities  of  the  hardware  and  soft- 
w«  feSXl  that  could  be  developed  within  the  next  several  year*  However 
the  antirinated  complexity  of  the  battle  management  software  and  the  neces  y 
2  «  KSasd  evolve  the  system  make  battle  management  and 
commandicontrol,  and  communication  (BM/C>)  the  paramount  strategic  defense 

problem.  .  , 

Software  technology  is  developing  against  indexible  limits  “  *he  'ompexity  an 
reliabilitv  that  can  be  achieved.  The  tradeoffs  necessary  to  make  the  software  task 
tractable^ ar^in  the  System  architecture.  As  indicated  in  the  Fletcher  Report,  the 
“applique  approach”  of  designing  the  system  first  and  then  writing 
control  it  is  the  wrong  approach  for  SDI.  System  architecture  and  battle  manage- 

ment  must  be  developed  together. 

One  promising  class  of  system  architectures  for  a  strategic  defense  system  are 
those  that  are  less  dependent  on  tight  coordination  than  what  is  implied  by 
F^h«  Lport  The  advantages  of  this  type  of  architecture  inc  ude  robustnes^, 
simplicity,  and  the  ability  to  infer  the  performance  of  full-scale  deployment  by  eval¬ 
uating  the  performance  of  small  parts  of  the  system.  The  panel  prefers  an  unc  - 

ventional  architecture  that  simplifies  the  software  reliable 

over  reliance  on  radical  software  development  approaches  Mid  the  risk  that 
software  could  not  be  developed  by  the  “applique  approach  at  any  cost. 
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I.  OVERVIEW 


The  SDtO  Panel  on  Computing  in  Support  of  Battle  Management  w^appoto^ 

for  a  research  and 

technology  development  program  to  implement  the  response. 

The  panel  met  for  17  days  during  the  summer  of  1985  Th«e 

-^S=S=S£5=ra 

These  additional  activities  included  reading  reports  and  articla  re  y  *  S°  ^ 
writing  this  report,  consulting  technical  experts  m  a  variety  of 
different  ideas  and  approaches,  performing  small-scale  compute, ^simulations  mid 
“contractor,.  All  information  that  the  panel  as  a  whole  discussed  and  the 

contents  of  this  report  are  unclassified. 

The  Dane!  members  appreciate  SDIO's  effective  way  of  instructing  them  to 

“Sts ^jrisrs£.*,=f=‘— 

research  details. 

This  nanel’s  study  follows  almost  two  years  after  the  report:  “Batt  e  .  an- 
This  panel  s  siuay  Processina”,  Volume  V  of  the  “Report  of 

aaement,  Communications,  and  Data  rrocessing  ,  #  M 

®  a.u  TVirpat  Posed  by  Nuclear  Ballistic  \lissiles  ,  Jame 

the  Study  on  Eliminating  the  Threat  rosea  oy  nu<.ic  -rwher 

<7  Fletcher  study  chairman.  We  hereafter  refer  to  tins  volume  as  the  Fletcher 
Reoort”  This  report  was  the  panel’s  Srst  reading  assignment  and  starting  point, 
it  £  a  very  insightful  early  study  of  many  of  the  same  problems  that  this  panel  as 

addressed. 

In  the  interest  of  making  this  report  more  readable  by  persons  who  l»ve  not 
studied  other  reports  on  the  Strategic  Defense  Initiative,  this  chapter  starts  with 
a  eeneral  discussion  of  SDI  and  the  problem  of  ballistic  missile  defense.  T 
body  of  this  overview  summarises  critical  technical  issues  and  the  panel  s  recom- 

mendations  to  SDIO. 

t  The  panel  wishes  to  thank  Bob  Balser,  Carl  Hewitt,  Jim  Horning,  David  Parma, 
and  Vic  Vyssotsky.  Particular  thanks  go  to  Vic  Vyssotsky,  who  '"  ^  understated 
way  provided  many  important  insights  to  the  software  development  task. 
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A.  Introduction 

From  "T he  President’s  Strategic  Defense  Initiative ”,  a  White  House  pamphlet  dated 
January  1985: 

“(SDI’s!  purpose  is  to  identify  ways  to  to  exploit  recent  advances  in  ballistic 
missile  defense  technologies  that  have  potential  for  strengthening  deterrence 
-  and  therefore  increasing  our  security  and  that  of  our  Allies.  The  program 
is  designed  to  answer  a  number  of  fundamental  scientific  and  engineering 
questions  that  must  be  addressed  before  the  promise  of  these  new  tech¬ 
nologies  can  be  fully  assessed.  The  SDI  research  program  will  provide  to  a 
future  President  and  a  future  Congress  the  technical  knowledge  necessary 
to  support  a  decision  in  the  early  1990s  on  whether  to  develop  and  deploy 
such  advanced  defensive  systems." 


SDIO  planners  consider  the  Strategic  Defense  Initiative  a  potentially  very  long- 
range  effort.  The  current  research  phase  is  aimed  at  providing  durmg  the  next 
several  years,  the  best  information  possible  concemmg  the  feasibility  and  cost  of 
alternative  new  approaches  to  ballistic  missile  defense. 

One  purpose  of  this  research,  phase  is  to  provide  the  technical  basis  f°r  a*1  un¬ 
formed  decision  by  a  future  administration  and  Congress  whether  to  proceed  to  he 
development  and  deployment  of  a  strategic  defense  system.  A  second  purpose  of 
this,  research  is  to  provide  a  scientific  base  on  which  the  engineering  development 
can  grow,  should  a  future  administration  and  Congress  decide  to  proceed  to  a  devel¬ 
opment.  As  is  essential  for  any  long-range  effort,  SDIO  sees  that  the  fundamental 
research  must  continue  concurrently  with  all  later  phases  of  the  initiative. 

The  panel  does  not  expect  small-scale  and/or  early  technology  deployments  that 
might  occur  during  the  1990s  to  provide  a  “near-perfect”  defense.  Rather,  initial 
deployments  influence  our  strategic  position  largely  in  their  ability  to  intercept 
enough  incoming  warheads  to  enhance  Soviet  attack  uncertainties.  Possible  Soviet 
countermeasures  such  as  fastburn  rockets  or  decoys  also  reduce  the  useful  payload 
of  their  missiles. 

At  the  rate  at  which  the  relevant  technologies  -  sensors,  weapons,  computing, 
and  communication  -  are  developing,  a  strategic  defense  system  of  the  2000-^010 
decade  could  provide  a  sufficiently  effective  defense  that  no  Soviet  planner  could  be 
reasonably  assured  of  the  “success”  of  a  ballistic  missile  attack.  The  United  States 
would  then  no  longer  need  to  depend  solely  on  an  offensive  deterrence.  Such  a 
system,  however,  would  still  require  us  to  upgrade  our  capabilities  to  reflect  advances 
in  the  base  technologies  and  changes  in  the  threat  situation. 
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The  research  is  then  directed  toward  a  defensive  system  that  is: 

•  Potentially  long-lived. 

•  Based  on  exploiting  advancing  technologies. 

•  A  step  beyond  existing  military  experience  and  doctrine. 

SDIO  accordingly  should  not  and  is  not  approaching  the  SDI  in  the  same  way  that 
the  DoD  ordinarily  “procures”  research  or  initiates  the  development  of  a  new  tank, 
^or"  Identifying  promising  technological  opportunitiestsapan^he 
research  problem;  the  research  is  expected  to  dedne  the  operauonal  requirements 
for  the  components  of  a  strategic  defense  system. 

If  developed  and  deployed,  the  longevity  of  a  strategic  defense  sy*«n ^clearly 
affects  the  formulation  and  implementation  of  the  computing  system  tha ^  controls 
it  The  system  must  be  capable  of  continuous  evolution  whde  in  reliable 
over  a  longer  period  of  time  than  has  been  foreseen  for  other  defense  sys 
This  requirement,  perhaps  the  most  fundamental  of  all  the  system  requiremen  s, 
influences  all  of  the  technical  issues  subsequently  described. 

B.  Physical  Characteristics 

The  following  review  for  the  lay  reader  may  be  taken  also  as  a. 
the  panel’s  working  assumptions  about  the  physical  characteristics  of  the  strateg 

defense  problem. 

The  physical  dimensions  of  the  battle  management  problem  are  wel|™d*ratood; 
A  ballistic  ^missile  can  first  be  intercepted  during  its  boost  phase,  which  lasts 
only  several  minutes.  During  this  phase  the  missile  emits  enormous  amounts  of 

energy  with  a  distinctive  spectral  signature  and  is  accordingly  ea^  to  ^^boost 
locatT  The  missile  is  also  a  relatively  large  and  fragile  target.  When  the  boost 
ohase  is  completed,  the  missile  releases  a  bus  containing  on  the  order  of  10  re*ntry 
vehicles  (RVs).  The  bus  then  launches  the  RVs,  each  into  a  slightly  different  ballistic 
trajectory  Future  buses  developed  in  response  to  defensive  systems  can  be  expected 
to  launch  both  RVs  and  decoys.  Interception  of  the  missile  in  the  boost  phase,  or 
of  the  bus,  offers  the  advantage  not  only  of  dealing  with  a  larger  target M*an  an 
RV,  but  also  of  eliminating  the  many  individual  targets  -  RVs  and  y 
are’ launched  from  the  bus  of  a  single  missile. 

During  the  midcourse  phase,  the  RVs  and  decoys  follow  a  baUistictrajecto^. 
This  phase  lasts  for  20-30  minutes  for  intercontinental  ballistic  missiles  (^BMs). 
The  ability  to  distinguish  RVs  from  decoys  is  obviously  advantageous,  and  SDIO 
is  researching  this  problem.  If  the  heavy  RVs  and  light  decoys  are  not  correctly 
distinguished  during  the  midcourse  phase,  whatever  of  them  remain  finally  sort 
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themselves  out  as  soon  as  they  start  to  reenter  the  Earth  s  atmosphere.  The  fin 
opportunity  for  defense,  the  terminal  phase,  may  last  as  little  as  40  seconds. 

The  midcourse  phase  for  submarine-launched  ballistic  missiles  (SLBMs)  may  be 
extremely  brief  to  nonexistent,  so  that  the  only  opportunity  to  intercept  them  may 
be  during  the  boost,  postboost,  or  terminal  phases. 

The  basic  concept  for  the  system  architecture  of  a  strategic  defense  system  is 
to  employ  at  least  three  tiers  in  the  defense:  at  least  one  for  each  phase.  Each  tier 
must  include  sensors  to  locate  the  targets  and  weapons  to  destroy  them. 

The  most  likely  technology  for  the  weapons  for  the  terminal  phase  defense  are 
ground-based  rockets  that  are  capable  of  very  high  acceleration  in  order  to  intercept 
the  incoming  RVs  at  a  high  altitude.  Weapons  able  to  intercept  missiles  in  the  boost 
phase,  however,  must  have  global  coverage  and  accordingly  must  be  in orbit.  e 
same  weapon  platforms  used  for  the  boost  phase  defense  could  also  be  used  for 
midcourse  defense,  since  the  requirements  on  their  geographical  distribution 
weapon  characteristics  are  similar.  The  space-based  weapon  platforms  might  e 
augmented  by  additional  ground-based  weapons  launched  only  after  the  beginning 

of  an  attack. 

The  orbiting  weapon  platforms,  at  an  altitude  of  several  hundred  kilometers, 
might  employ  either  kinetic  energy  weapons  (KEWs)  or  directed  energy  weapons 
(DEWs).  We  will  assume  that  the  useful  range  of  either  of  these  types  of  weapons 
is  about  2000km.  This  range  is  determined  in  part  by  weapon  characteristics  an 
in  part  by  the  line-of-sight  from  the  altitude  of  the  platform.  The  weapon  platforms 
would  be  put  into  a  set  of  orbits  that  are  synchronized  to  each  other  (not  geosyn¬ 
chronous),  thus  ensuring  approximately  uniform  coverage  of  the  entire  Earth  s  sur¬ 
face  at  all  times.  Random  orbits  are  not  desirable  because  they  produce  predictable 

holes  in  the  coverage. 

The  kinetic  energy  weapons  are  high-speed  rockets  or  bullets  that  destroy  tar¬ 
gets  by  impact.  These  kinetic  energy  weapons  appear  to  be  the  most  feasible  for 
early  deployments.  Their  advantages  include  a  lack  of  dwell  time,  which  DE  s 
have,  and  their  consequent  rapid  firing  rate.  There  may,  in  other  words,  be  many 
KEWs  fired  in  a  short  interval  from  a  single  weapon  platform.  The  disadvantages  of 
KEWs  relative  to  DEWs  include  their  limited  (expended)  ammunition  and  the  delay 
between  firing  and  being  able  to  assess  whether  the  shot  destroyed  the  target.  The 
directed  energy  weapons  do  not  appear  to  be  candidates  for  early  deployments  but 
offer  possible  advantages  when  they  are  fully  developed.  None  of  these  space-based 
weapons  is  capable  of  causing  damage  at  the  Earth’s  surface. 

Some  space-based  sensor  platforms  would  be  located  in  high  orbits;  others  m 
low  orbits  or  combined  with  weapon  platforms.  The  space-based  sensors  can  be 
passive,  detecting  targets  by  their  electromagnetic  radiation,  including  their  thermal 
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radiation.  Other  sensors  such  as  terminal  defense  radar  could  be  located  on  the 
ground  or  in  aircraft. 

All  the  system  resources  would  be  tied  together  with  a  commumcation  system 
and  would  operate  under  control  of  the  battle  management  system. 
battle  management,  command,  control,  and  commumcation  (BM/C  )  .ssues 
we  discuss  in  the  later  sections  of  this  overview  and  repor  . 

The  fraction  of  our  force  that  can  be  applied  during  the  boost  phase  depends 

on  the  area  distribution  of  missile  launches.  With  a  2000km  ran«e»*®c  5Ppercent 
covers  about  2.5  percent  of  the  Earth’s  area.  The  significance  of  this  2  o  percent 
figure  is  that  the  fraction  of  our  force  that  could  be  used  in  the  boost  phase 
relaunches  were  from  one  place  is  2.5  percent.  Curiously,  the  ideal  deployment 
aeainst  a  defensive  system  is  concentrated,  while  the  ideal  deployment  against  an 

With  a  launch  area  as  large  as  1000  by  2000km  about 

10  percent  of  our  defeLve  force  could  be  applied  during  boost  phase,  plus  whatever 
could  be  used  against  SLBMs. 

These  numbers  relating  to  the  fraction  of  our  forces  that  could  be  W  are 
independent  of  the  number  of  weapon  platforms  only  if  there  are  sufficient  platforms 
for  full  coverage.  Boost  phase  coverage  in  partial  (early)  deployments  o  weapo 
platforms  would  be  nil.  On  the  other  hand,  high  altitude  sensor  platforms  ine^Y 
deployments  have  the  potential  of  providing  earlier  warning  of  a  ballistic  missile 
attack  than  existing  ground-based  systems.  Generally,  even  for  a  given  number  of 
weapons,  it  is  better  if  they  are  distributed  over  more  platforms,  since  the  average 
then  smaller,  and  the  effect  of  one  being  destroyed  or  out  of  service  is 
not  as  severe.  Use  of  orbiting  defensive  forces  during  the  midcourse  phase 
favorable:  30-40  percent  according  to  simulations. 

Necessary  accuracy  and  resolution  in  weapons  and  sensors 
A  pointing  accuracy  of  1  arcsec  is  within  a  5m  error  radius  at  1000km.  This  sam* 
resolution^  at  the  diffraction  limit  for  green  light  with  an  0.1m  aperture.  Objects 
-  platforms  and  targets  -  moving  at  orbital  velocities  are  moving  fast  ^ough  tha 
speedi-light  delays  must  be  compensated.  For  example,  when  the  electromagnetic 
sfgnal  from  an  object  moving  at  orbital  speed  reaches  a  sensor,  it  is  a.rea  y 
further  along  its  path  for  each  40km  distance  to  the  sensor. 

C.  Battle  Management  Policy  and  Doctrine 

Historically,  the  pattern  used  for  the  acquisition  of  weapons  systems  has  been 
to  acquire  the  weapoL  first  and  devise  the  command,  control,  and  communication 
(C5)  m  an  accessory.  The  Fletcher  Report  made  the  pent  that  this  aPPU^e 
approach”  is  the  wrong  approach  for  SDI.  The  panel  strongly  agrees-, : ^ 
battle  management  and  Cs  problem  as  the  paramount  technical  issue  that  must  be 
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resolved  in  order  to  implement  a  strategic  defense  system. 

Defining  the  military  operational  requirement  (MOR)  is  one  initial  key  to  the 
architectural  development.  Clear  definitions  within  the  various  descending  levels  of 
operational  “needs”  in  the  MOR  are  necessary  at  the  outset.  Simply  stated: 

•  Either  the  end  user,  the  military,  states  its  needs  and  the  architecture  developer 
produces  to  those  criteria,  or 

.  Regardless  of  the  operational  requirement,  the  developer  uses  his  assumptions 
to  produce  an  architecture  within  which  the  end  user  is  constrained. 


If  various  teams  of  competing  contractors  were  devising  candidate  architectures 
that  satisfied  a  common  MOR,  the  eventual  selection  process  could  start  from  a 
common  basis  of  understanding. 


Unfortunately,  the  task  is  not  that  simple.  The  military  operational  require¬ 
ments  for  a  strategic  defense  system  -  a  system  that  has  no  clear  precedent  in 
military  experience  -  have  not  been  devised.  The  "problem”  of  strategK  defense 
is  imprecisely  posed  in  the  best  sense:  The  objective  is  clear,  and  the  exploration 
of  means  to  achieve  the  objective  is  most  appropriately  conducted  with  many  de¬ 
grees  of  freedom.  SDI  research  should  gradually  make  the  range  of  possibilities  and 
solutions  more  precisely  understood. 


Although  the  panel  has  discussed  possible  strategies  and  doctrine,  the  answers 
to  many  questions  involve  considerations  that  are  beyond  the  panel’s  expertise.  For 
example,  to  what  extent  should  one  consider  attacks  against  the  defense  system 

itself? 

It  appears  that  the  SDI  Phase  If  architecture  contractors  used  Volume  V  of  the 
Fletcher  Report  as  their  “common  baseline”  by  default.  The  panel  observes  that 
the  technical  problems  of  the  system  architecture  and  software  development  for  a 
battle  management  system  are  interwoven  with  the  entire  problem  of  defining  also 
-  perhaps  only  after  several  phases  or  iterations  -  the  MOR,  policies,  and  strategies 

for  its  use. 


This  observation  implies  the  need  for  flexibility  in  the  architectural  development. 
One  can  anticipate  various  transitional  phases  in  any  eventual  deployment  of  the 
SDI  system.  One  can  visualize  sensors  of  a  defensive  system  that,  at  the  time  o 
their  initial  operational  capability  (IOC),  would  serve  operational  aspects  of  both 
offensive  and  defensive  actions.  Use  of  SDI  sensors  for  warning  of  a  ballistic  missile 
attack  does  not  imply  an  automatic  response.  In  fact,  it  could  provide  additiona 
time  for  the  human  decision-making  process. 


t  The  term  “Phase  I”  refers  to  the  first  phase  of  the  “System  Architecture  Key 
Tradeoffs  Study”  conducted  by  SDIO  early  in  1985. 
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As  the  defensive  system  expands  in  numbers,  capabilities,  and  reliability,  one 
can  exDeTt  the  Offensive  deployments  to  diminish.  The  evolving  ardutecture  and 
b«t“C^«“stem Laid  be  able  to  accommodate  the  changing  nature  of 

the  force  deployments. 

While  the  system  evolves,  one  should  recognise  that  human  intervention  is  n«- 

essary  to  i control  strategic  operational  forces.  The  same  degree  of  «**»*>■£ 
fa,  Ae  strategic  offense  may  not  be  required  for  a  solely  defensive  force.  Thus,  the 
eventual  process  of  political  approval  for  SDI  could  lead  to  alterations  in  the ■  m a  ary 
doctrine  employed  by  the  operational  forces.  The  system  will  require  continuous 
user-developer  tolerations  to  ensure  that  the  architecture  meets  the  evolving  threa 

and  the  dictates  of  national  policy. 

D.  Battle  Management  Principles 

The  most  plausible  organisations  for  a  strategic  defense  battle  management 
system  are  hierarchic.  That  is,  their  communication  and  information-processing 
structure  can  be  portrayed  graphically  in  “tree"  diagrams  such  as  an  orgamzation 
chart  or  depiction  of  a  chain  of  command.  This  hierarchy  or  tree >  rtructow  of  a 
battle  management  system  is  rooted  in  the  command  authority  and  branches  to  the 
sensor  and  weapon  subsystems.  The  properties  of  such  hierarchic  are  ^ 

well  understood  both  analytically  and  by  analogy  to  this  same  organization  ha  m0 
been  adopted  by  living  creatures  and  their  social  organizations. 

Such  systems  have  the  property  that  information  sensed  at  the  “l^ves”  °f  the 
tree  is  processed  (compressed)  into  more  abstract  representations  as  it  is  commu¬ 
nicated  toward  the  root,  and  is  articulated  from  abstract  representations  to  < de »  ai 
commands  as  it  is  communicated  toward  the  leaves.  This  communication  and  com¬ 
putation  structure  preserves  locality  and  allows  for  autonomous  actions  fwm  lo 
subunits,  which  have  the  same  tree-like  structure  as  the  entire  system.  Wien  th 
communications  are  augmented  with  lateral  paths,  the  hierarchy  can  as°  * 
fault-tolerant.  The  (superficial)  variations  on  this  basic  architecture  are  define 
by  the  number  of  levels  and  functional  definition  of  the  levels,  particularly  their 

capability  for  independent  action. 

This  hierarchic  organization  determines  the  logical  structure  of  the  communi¬ 
cations  within  the  battle  management  system  and  accordingly  strongly  influences 
its  physical  organization.  The  hierarchic  structure  also  influences  the  strategies  for 
managing  the  complexity  of  the  battle  management  system  software. 

One  should  regard  the  sensor  and  weapon  parts  of  a  strategic  defense  system  as 
well-defined  subsystems  analogous  to  computer  “peripherals" .  Although  the  sensors 
and  weapons  can  be  expected  to  have  self-contained  computational  resourc<* 
tasks  such  as  signal  processing,  aiming,  message  processing,  and  self  maintenance, 
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they  themselves  do  not  hove  any  responsibility  for  coordinating  their  actions  with 
those  of  other  platforms  or  for  allocating  resources. 

This  model  is  consistent  with  the  notion  that  the  software  for  sensors  and 
weapons  could  he  largely  conventional  and  tied  closely  to  the  technology  and [  capa¬ 
bilities  of  the  particular  subsystem.  For  example,  a  sensor  subsystem  might  have 
the  ability  to  accept  commands  to  search  a  given  area  for  a  particular  signatur  . 

It  could  articulate  this  command  into  the  suitable  actions  of  pointing  its  sensors, 
performing  the  required  image-processing  operations,  and  reporting  the  results,  n 
as  an  image,  but  as  a  set  of  measurements. 

The  battle  management  system  and  software  are  then  defined  as  those  parts 
of  the  system  that  deal  with  coordination.  One  can  envision  many  different  types 
of  coordination,  each  with  its  own  purpose,  latency  requirements  and  performance 
benefit.  Different  types  of  coordination  require  more  or  less  of  the  entire  system  o 
be  involved,  and  therefore  would  be  accomplished  at  different  levels  m  the  logica 

hierarchy.  Examples: 

.  Lowest  levels:  It  would  be  desirable  for  certain  low-level  coordination,  such  as 
stereo  and  other  “sensor  fusion*  operations,  to  occur  as  close  to  the  leaves  of 
the  hierarchy  as  possible. 

•  Middle  levels:  Target  discrimination  and  attack’ coordination  (assuring  complete 

coverage,  avoiding  multiple  shooting)  might  well  occur  at.  the  middle  levels  o  ^ 
the  hierarchy. 

.  High  levels:  The  assignment  of  priorities  of  targets  in  midcourse  in  order  to 
prevent  particular  areas  from  being  overwhelmed  in  terminal  defense,  or  uo 
prevent  any  single  area  from  accepting  too  high  a  concentration  for  termma 
defense,  requires  global  information  that  must  be  processed  close  to  the  root  of 

the  hierarchy. 

•  Highest  levels:  High-level  command  and  control  decisions  defer  to  the  root. 

Although  all  of  the  panel’s  briefings  have  emphasized  that  the  logical  organiza¬ 
tion  does  not  determine  the  physical  organization,  in  practice  there  is  every  reason 
in  such  a  distributed  system  to  pattern  the  physical  organization  after  the  logical 
organization.  In  fact,  with  satellites  in  different  orbits,  one  wishes  general ly  to  keep 
the  system  in  a  logical  configuration  that  reflects  the  current  geographical  distribu¬ 
tion  of  the  satellites.  In  other  words,  the  orbiting  assets  would  not  be  regarded  as 
a  single  system;  they  would  be  organized  into  “battle  groups  Membership  in  the 
groups  would  change  dynamically  according  to  the  patterns  of  the  orbits  and  e 

serviceability  of  the  platforms. 
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This  distributed  approach  to  battle  management  minimises  the  communication 
latency* mid*  required  bandwidth,  as  well  as  the  consequences  of  interruptions  of 
communication  or  loss  of  system  resources.. 

E.  Phase  I  System  Architectures 

VrtinTnp  V  of  the  Fletcher  Report  describes  a  battle  management  approach  that 
,  ™ 8  ™  It;  * Twme"  example  that  the  computation  and  common, 
should  e  rp  battle  management  are  within  reasonable  technological 

Ca^rThT—n  oT"A^.^ure  for  Battle  Management"  inciudes  the 
caution  that  it  “...is  not  intended  as  a  design  manual  . 

The  Phase  I  contractors  who  made  presentations  to  the  panelt  «wsrth.l«s 
followed  the  Fletcher  Report  approach  very  closely  -  certain  y  more 
the  authors  intended. 

Although  much  of  the  Fletcher  Report  discussion  is  centered  "ou"d 
data  base  including  a  track  file  of  all  objects,  the  report  indicates  that  there  ar 
.“B(B  n  *  ding  attention  in  the  design  of  systems  that  depart  from  the 

The  proposed  Phase  I  system  architectures  presented  to  the  panel  were  devel¬ 
oped  around  sensors  and  weapons.  In  spite  of  the  sound  advice  in  Volume  V  of  the 
Fletcher  report  that  “the  battle  management  system  and  its  software  mu 
staed  LTmtegral  part  of  the  ballistic  missile  defense  (BMD)  system  as  a  who  e 
annliaue”  these  contractors  treated  the  battle  management  compu  g 
a'  part  of  the  system  that  could  b. 

added.  The  contractors  treated  battle  management  “  ““ethl"«  *h**“ 
to  represent  less  than  five  percent  of  the  total  cost  of  the  system,  and  therefore 

could  not  significantly  affect  the  system  architecture.  They  have 

proposed  architectures  around  the  sensors  and  weapons  and  a^he  entire 

vice”  to  the  structure  of  the  software  that  must  control  and  coordinate  the  entir 

system. 

+  The  nanel  received  presentations  from  several  contractors,  who  will  remain 
unidentified  here.  We  were  told  that  SDIO  regarded  the  studies  produced  by  these 
contractors  as  among  but  not  necessarily  the  best,  and  thi 
of  the  diversity  of  approaches  that  the  contractors  had  come  up  with. 
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As  a  result,  none  of  the  architectures  presented  to  the  panel  adequately  ad¬ 
dresses  the  key  issues  of  structuring  the  system  architecture  to  (1)  make  the  battle 
management  software  task  tractable,  and  (2)  accommodate  testing  and  evolution 
of  the  system  and  software. 

Similarly,  SDIO  should  guard  against  the  assumption  that  only  the  physical 
requirements  implied  by  the  sensor  and  weapon  characteristics  drive  the  system 
architecture.  In  fact,  the  battle  management,  system  integration  and  evolution, 
and  testing  requirements  have  at  least  as  much  impact  on  the  system  architecture. 
The  SDIO  organizational  separation  of  system  architecture  from  battle  management 
should  not  be  allowed  to  keep  these  aspects  of  strategic  defense  from  being  developed 

together.! 

F.  System  Architecture 

The  panel  concluded  that  computing  resources  and  battle  management  software 
for  a  strategic  defense  system  are  within  the  capabilities  of  the  hardware  and  soft¬ 
ware  technologies  that  could  be  developed  within  the  next  several  years.  The  panel 
cautions,  however,  that  the  feasibility  of  the  battle  management  software  and  the 
ability  to  test,  simulate,  and  modify  the  system  are  very  sensitive  to  the  choice  of 
system  architecture.  In  particular,  the  feasibility  of  the  battle  management  system 
software  is  much  more  sensitive  to  the  system  architecture  than  it  is  to  the  choice 
of  software  engineering  technique.  , 

Accordingly,  the  recommendations  that  .the  panel  regards  as  most  important 
concern  the  relationship  between  the  system  architecture  and  the  feasibility  of  the 
battle  management  system  software.  Software  technology  is  developing  against  what 
appears  today  to  be  relatively  inflexible  limits  in  the  complexity  and  reliability  that 
can  be  achieved.  The  tradeoffs  necessary  to  make  the  software  task  tractable  are  in 
the  system  architecture. 

As  indicated  in  the  Fletcher  Report,  the  “applique  approach”  for  the  software 
is  the  wrong  approach  for  SDI.  The  problem  of  reducing  software  complexity  must 
be  treated  as  the  principal  influence  of  the  system  architecture. 

In  short,  the  panel  recommends  a  broader  study  of  system  architectures  than 
is  represented  by  the  Phase  I  efforts,  with  the  objectives  stated  previously.  The 

t  In  The  Mythical  Man-Month:  Essays  on  Software  Engineering,  Addison- Wesley, 
1974,  Frederick  P.  Brooks,  Jr.  says:  “Conway’s  Law  predicts:  ‘Organizations  which 
design  systems  are  constrained  to  produce  systems  which  are  copies  of  the  com¬ 
munication  structures  of  these  organizations.’  Conway  goes  on  to  point  out  that 
the  organization  chart  wiU  initially  reflect  the  first  system  design,  which  is  almost 
surely  not  the  right  one.  If  the  system  design  is  free  to  change,  the  organization 
must  be  prepared  to  change.” 
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pane!  much  prefer,  an  unconventional  ,y,tem  architecture  who* 

by  the  “applique  approach”  at  any  cost. 

For  — m.  a  promising  class  of  system  architecture,  for  a  strategic  defense 
system  are  thLe’that  are  less  dependent  on  tight  coordination  than  what  is  imp  le 
•  f.  pifL_  panort  There  are  several  aspects  that  make  this  type  o 
££  p^mgTa'st^nic  defense  system.  They  are  robustness  simpUc^ 
and  the  ability  to  infer  the  performance  of  full-scale  deployment  by  evalua  mg 
performance  of  small  parts  of  the  system. 

The  Fletcher  Report  suggests  as  an  -ideal"  -  a  ^  “  ^"uch 

in  an  implementation  -  a  very  central  architecture  («.$.,  the  track  files). 

srttsr s?  it,r^s.rsr. 

and  synchronization. 

In  conventional  large  distributed  systems  there  are  important  of 

consistency  and  synchronisation  of  all  the  data  bases.  For  exampte  » 
ing  system  has  a  global  state  that  reflects  every  transaction  lh»*  0  “7.J.  th.  ' 
artionA  are  serialized  'in  order  to  maintain  a  valid  total  state.  A  loss  o 
smallest  transaction  can  invalidate  that  “historic”  state.  A  strategic  ^ 
does  not  have  to  maintain  either  global  consistency  or  global  infinite  response  state. 
It  should  distribute  its  functions  while  maintaining  only  central  command  auth  y 
and  global  situation  assessment. 

The  panel  has  discovered  that  tight  coordination  of  the  system  assets  in  cer- 
tain  cases  (e  g.,  to  achieve  a  complete  coverage  and  to  avoid  double  shooting  1 

provides  relatively  slight  (*20  percent)  improvement  ^^  “  ^ 

a  potential  source  of  many  technical  difficulties  in  reliability  and  testability.  Some 

forms  of  coordination  are  still  essential,  for  example: 

•  Tight  coordination  is  required  for  central  command  authority. 

•  Tight  coordination  is  required,  but  only  over  localized  zones,  for  processing 
multiple  (stereo)  sensor  information. 

.  Loom  (optional,  or  not  tims-critical)  coordination  is  required  for  the  selection 
of  targets  during  the  midcourse  phase,  based  on  discrimination  informati 
avoiding  concentrations  in  the  terminal  phase. 
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Future  architectural  studies  should  examine  the  consequences  of  reducing  the  as- 
stimed  degree  of  coordination  of  system  parts. 


G.  Testing 

A  deployed  strategic  defense  system  must  evolve  with  technology  and  perceived 
threat.  This  requirement  is  also  a  necessary  property  of  our  strategic  offense,  e 
Triad,  and  of  each  of  its  components,  as  well  as  of  high-technology  defensive  forces 
such  as  antisubmarine  warfare.  These  systems  are  not  only  continuously  upgrade  , 
but  are  also  subjected  to  frequent  tests  -  whether  technical  tests  or  military  exercises 
-  that  provide  the  assurance  that  they  can  be  depended  on  if  needed. 

There  is  an  obvious  synergy  between  evolution  and  testing.  One  must  realize, 
however,  that  short  of  a  war,  there  can  never  be  a  full-scale  test  of  a  strategic 
defense  any- more  than  there  can  be  a  full-scale  test  of  our  strategic  offense.  There 
are  two  reasons  why  we  can  be  confident  of  our  strategic  offense: 


•  Independence:  The  effects  of  the  forces  are  believed  to  be  additive.  For  example, 
if  one  particular  missile  has  been  tested  20  times  and  has  been  on  target  16  times, 
we  can  assume  that  these  numbers  can  be  adjusted  proportionately  to  reflect 
results  of  an  actual  attack.  One  missile’s  malfunctioning  does  not  generally 

cause  another’s.  •  t 

•  Diversity:  There  is  a  useful  diversity  in  the  Triad  and  each  of  its  components, 
so  that  even  if  the  Soviets  were  to  develop  an  effective  countermeasure  for  one 
weapon  or  system,  the  others  provide  a  credible  deterrent. 

‘  A  full-scale  strategic  defense  system  would  not  be  expected  to  involve  more 
military  hardware  than  any  one  component  of  the  Triad.  What  makes  it  different. 
A  characteristic  of  a  strategic  defense  system  that  could  make  it  difficult  to  test 
to  the  point  of  full  confidence  is  an  excessive  reliance  on  coordination  between  the 
parts  of  the  system.  Because  coordination  is  a  battle  management  system  function, 
the  requirement  of  testability  falls  most  seriously  on  the  formulation  of  the  battle 
management  system  and  system  architecture. 

Computing  systems  involving  complex  interactions,  such  as  operating  systems, 
may  appear  to  work  perfectly  under  light  computing  loads  and  ideal  assumptions, 
but  they  may  fail  when  heavier  loads  create  unexpected  combinations  of  delays 
and/or  faults  in  the  system  or  its  peripheral  parts.  Simple  oversights  cause  most 
of  these  failures,  but  some  are  due  to  the  very  large  number  of  combinations  of 
circumstances  that  must  be  anticipated  in  writing  the  program. 

The  ability  to  have  confidence  in  a  total  strategic  defense  system  is  a  critical 
technical  point  that  must  be  addressed  as  a  central  objective  of  the  battle  manage- 
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ment  system  and  system  architecture.  There  are  several  approaches  to  this  testing 
problem  that  are  promising: 

.  Develop  system  architectures  in  which  there  is  relatively  little  de P«tdence  on 
coordination  or  in  which  the  coordination  information  is  used  only  if  available. 
Th«  architectures  are  relatively  easier  to  test  in  parts  and  possess  other  ad- 
vantages  mentioned  in  previous  sections. 

.  Us.  simulation  extensively,  using  very  high-speed  and/or  highly  ~entprc, 
grammable  computers  that  would  allow  the  operational  code  an  g 
b^tMted  under  very  large  numbers  of  battle  variations.  It  should  be  possible 
to  employ  such  simulations  to  aid  in  debugging  and  in  performance  eva  ua  ion 

under  varying  tactics. 

•  Develop  in-linef  testing  of  a  deployed  system,  with  simulated  data  going  to  and 
ft om  theMnsor  and  weapon  platforms.  Hierarchically  organised  systems  lend 
themselves  readily  to  this  type  of  tasting.  Such  testmg  should  be  employed 
on  the  ground  and  as  an  ongoing  process  in  a  deployed  system. 

Again,  one  must  consider  that  the  tradeoffs  required  to  make  a  strategic  defense 
system^testable  are  found  in  part  in  the  formulation  of  the  system  architects  to 
this  case  the  ability  to  infer  by  testing  parts  of  the  system  the  performance  of  th 
entire  system  is  analogous  to  the  case  of  the  strategic  offense. 

H.  Simulation 

Simulation  is  vitally  important  to  two  aspects  of  SDI  research 
ment.  First,  simulation  is  necessary  to  explore  the  way  in  which  a  vane  y  > 
architectures  perform  against  many  possible  attacks  and  under  different  circum¬ 
stances  involving  system  Saws  and  component  failures.  Simulation  is  an  excellen 
vehicle  to  support  such  design  studies.  Second,  simulation  allows  subsystems  to  be 
tested  while they  are  under  development,  and  many  of  the  same  techniques  can  b 
extended  to  in-line  testing  of  a  deployed  system. 

A  simulation  system  itself  consists  of  computers,  simulation  language  software, 
and  simulations  of  weapons,  sensors,  and  communication  channels^  J?b 
simulation,  the  simulator  monitors  and  computes  the  physical  evolution  of  the  bat 
tlefield  map”  while  interfaced  to  prototype  or  actual  BM/C  software  and .  a  a  _ 
scenarios.  An  essential  and  often  overlooked  component  of  simulation  is  validati 
-  the  effort  required  to  ensure  that  the  simulation  is  realistic. 

t  ‘In-line’  refers  to  the  technique  of  testing  components  end  system  in  their  actual 
operating  environment  rather  than  on  a  “test  bench" . 
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The  panel  recommends  the  implementation  of  several  simulation  systems  for 
evaluating  battle  management  architectures  and  strategies.  Multiple  simulations 
provide  cross-validation,  verification,  and  a  higher  level  of  confidence  in  the  results. 
Further,  the  panel  recommends  the  use  of  independent  validators  whenever  possible, 
including  efforts  by  research  and/or  academic  groups. 

The  panel  recommends  also  the  implementation  of  several  detailed  simulators 
capable  of  supporting  BM/C3  software  in  three  forms:  simulated,  prototype,  and 
actual.  These  simulators  would  serve  initially  for  debugging  and  simulated  testing; 
later  they  would  provide  in-line  tests  of  the  system  through  its  ability  to  interface 
with  real  sensors,  communication  channels,  and  weapons.  The  simulators  should 
be  capable  of  multilevel  simulation  in  which  different  aspects  of  the  system  are 
represented  at  different  levels  of  detail. 

These  simulators  should  be  able  to  cooperate  in  large,  distributed  system  sim¬ 
ulations.  The  simulation  facility  should  not  be  centralized  at  and  restricted  to  the 
proposed  National  Testbed  (NTB).  The  simulation  effort  will  benefit  significant  y 
in  quality  and  credibility  if  it  is  not  “kept  behind  walls”.  The  simulators  should 
have  extensive  facilities  for  measurement,  monitoring,  and  debugging.  Again,  one 
of  the  reasons  for  having  a  diversity  of  simulators  is  for  establishing  verification  and 

cross-validation. 

Battle  management  simulators  should  be  developed  early  in  order  to  evaluate 
BM/C3  system  designs,  and  the  results  of  those  studies  should  be  incorporated  into 
ongoing  architectural  efforts. 


I.  Software 

The  panel  has  discussed  software  technology  issues  extensively.  The  panel  has 
also  discussed  this  subject  with  experts  in  the  software  field. 

Simply  because  of  its  inevitable  large  size,  the  software  capable  of  performing 
the  battle  management  task  for  strategic  defense  will  contain  errors.  All  systems 
of  useful  complexity  contain  software  errors.  Therefore,  for  .  the  very  high  level  of 
reliability  required  for  a  strategic  defense  system,  the  central  question  is  how  to 
design  this  system  such  that  errors  are  first  minimized  and  then  tolerated. 

In  evaluating  the  impact  of  software  errors,  one  should  distinguish  between 
errors  that  are  system-critical  and  those  that  are  not.  For  example,  the  Shuttle 
software  has  errors  that  become  famous  whenever  a  launch  is  delayed,  but  the 
Shuttle  has  never  encountered  any  error  in  the  critical  ascent /descent  code. 

Techniques  for  constructing  systems  that  are.  usefully  reliable  in  spite  of  imper¬ 
fection  is  not  in  the  current  mainstream  of  software  engineering  research.  Some 
practitioners  of  software  engineering  are  more  concerned  today  with  making  their 
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Sv«  been  used  before;  some  have  only  bean  discussed  but  not  senously  applied 
projects  due  to  time  and  cost  limitations;  some  are  research  topics. 

The  panel  advises  SDIO  not  to  expect  any  single  software  technology  to  be  te 
1  *•  P  tim  bullet”  -  for  the  SDI  battle  management  system.  Instead 

SDIoThould  use  proven  software  technologies  as  they  fit  each  part  of  the  ^ 
Forexample  the  panel  does  not  expect  automatic  programming,  program  ver.6- 
cation,  artificial  intelligence,  or  knowledge-based  expert  systems  to  be  suBcien 

themselves. 

The  panel  expects  the  realistic  approach  to  the  battle  management 
be  an  open,  distributed,  adaptive  self-  and  cross-checking  sys 
redundancy. 

j  fl^rdwsrc 

Unlike  the  software  technology,  where  progress  has  been  and  will  My contmue 
to  be  relatively  slow,  the  panel  expects  that  hardware  techno  ogy  tems 

oronress  rapidly.  Advances  in  both  devices  and  architectures  are  leading  y 

increased  computing  speed  is  combined  with  ***££*££  “d 

power.  This  progress  is  a  resuit  of “™d The VLSI 
government-sponsored  efforts  sudh  as  the  VHSIC  p  gr 
and  Strategic  Computing  programs  of  DARPA. 

The  panel  therefore  recommends  that  the  SDI  «ploit  the  advanced  compuler 

conservative  use  of  computers  in  all  areas. 

A  very  important  area  for  immediate  attention  is  the  SDI  space  qu ^aiificaUon 
process  Technology  insertion  delays  are  significant  in  the  space  application  . 
understanding  of  Ae  space  environment  and  of  behavior of  1 hardware  in  s ipace 
now  available  This  knowledge  together  with  progress  m  the  design  of  VLSI  circuits 
using  innovative  design  tools  provide  an  excellent  opportunity  to  deliver  the  current 

technology  in  space. 

It  will  be  necessary  to  propagate  a  different  culture  of  system  development  to 
exploit  the  emerging  technologies.  Insertion  of  technology  squires  a  continuous 
upgrading  of  method  that  are  consistent  with  new  techniques,  ^ 
project  schedules,  lack  of  capable  staff,  procurement  decisions,  ^  <™r  y 
have  created  an  industrial  culture  that  resists  change.  We  must  create  a  culture  that 
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is  able  to  adapt  to  changes  more  effectively  than  we  currently  do.  This  objective 
requires  that  we  study  causes  and  develop  practices  that  encourage  and  reward 
responsible  effort  toward  technology  insertion. 


K.  Communication 


Another  unnecessary  architectural  assumption  derived  from  taking  the  Fletcher 
Report  beyond  its  intention  is  the  form  of  networking  of  the  system  assets.  Using 
the  sensor  and  weapon  platforms  also  as  the  communication  backbone  rather  than 
considering  a  network  of  satellites  dedicated  to  communication  could  negatively 
affect  reliability,  flexibility,  and  cost  of  deployment. 


The  communication  approach  proposed  in  the  Phase  I  studies  reflects  a  mis¬ 
perception  of  the  issues  that  drive  the  solution.  If  the  communication  approach  is 
driven  by  the  hardware  rather  than  by  the  problem,  the  solution  focuses  on  data 
transmission  rates  rather  than  on  information  exchange.  This  approach  has  already 
focused  attention  on  the  transmission  capability  and  ignores  packet  processing,  en¬ 
cryption/decryption,  and  error  correction,  in  spite  of  the  existing  disparity  etween 
feasible  rates  for  raw  transmission  and  packet  processing. 


SDIO  should  study  and  develop  communication  networks  that  address  the  spe¬ 
cific  and  unique  requirements  of  the  strategic  defense  system. 


The  panel  recommends  also  that  SDIO  build  an  “SDInet"  to  serve  as  a  prov¬ 
ing  grounds  for  the  distributed  system  architecture  of  the  strategic  defense  system 
and  for  its  communication  protocols.  The  SDInet  wiU  support  interoperability  of 
architecture  work,  battle  management  development,  and  simulation  facilities.  The 
SDInet  will  also  support  resource  sharing  among  the  SDI  contractors. 


L.  Program  Management 

The  scope  and  rate  of  advance  of  the  technology  areas  associated  with  the  SDI 
BM/C3  investigation  presents  SDIO  with  a  large  and  complex  management  problem. 
Such  a  program  clearly  requires  technical  direction,  progress  review  and  evaluation, 
and  effective  program  management  and  contracting  practices.  The  special  char¬ 
acteristics  of  the  program,  particularly  its  dependence  on  advancing  technologies, 
justify  innovative  approaches  to  program  management. 

The  panel  recommends  that  SDIO  use  independent  contractors  to  perform  the 
technical  functions  of  program  managers  in  those  areas  in  which  SDIO  can  not  enlist 
personnel  of  the  appropriate  technical  caliber.  This  use  of  contractors  would  allow 
SDIO  to  tap  the  talent  of  leading  researchers  in  the  scientific  community. 

An  SDI  technical  infrastructure  should  be  developed  to  provide  a  resource- 
sharing  mechanism  and  to  promote  the  creation  of  an  SDI  technical  community.  The 
SDI  contractors  should  be  linked  together  via  SDInet,  a  computer  communication 
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network.  This  network  would  allow  contractors  to  exchange  ec  me  a 
and  software;  it  would  promote  compatibility  and  cooperation. 

snTO  should  sponsor  research  in  the  areas  of  program  management  and  con- 
SDIO  should  sponsor r .  gDI0  ^  adapt  tQ  a  rapidly  evolving 

LTZngtag  e  ”'iroolentAs  a  result,  SDIO  needs  a  program  management  store- 
ng  method  that  aUo*  it 

as  technology  issues  are  resolved.  Automated  means  ot  tracKingprugi 
ren^im^e  needed,  as  are  special  contracting  methods,  or  changes  m  spec, he 

DoD  program  management  guidelines. 
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II.  DOCTRINE  AND  POLICY 


Generally,  developments  in  weapons  technology  have  led  to  operational  concepts 
and  a  body  of  military  doctrine  that  governs  the  use  of  those  developments.  In 
similar  vein,  the  pattern  used  in  the  United  States  for  the  acquisition  of  weapons 
systems  has  been  to  acquire  the  weapons  first  and  devise  the  supporting  command, 
control,  and  communications  (C3)  structure  as  an  add-on.  For  the  SDI,  the  pane 
has  determined  that  the  opposite  is  necessary  -  that  the  battle  management  sys  em 
and  its  supporting  C3  must  become  the  primary  developmental  factors.  Thus,  SDiu 
should  develop  the  strategic  defense  C3  first,  then  add  the  weapons  and  non-C 
sensors,  which  one  could  call  “peripherals”  at  this  stage  of  the  research  effort.  The 
Fletcher  Report  stressed  that  a  C3  “add-on”  or  “applique”  approach  is  the  wrong 


approach  for  SDI. 

In  addition,  the  need  for  a  definite  statement  regarding  the  military  operational 
requirement  (MOR)  is  the  initial  key  to  the  system’s  architectural  development 
Clear  and  definitive  statements  within  the  various  descending  levels  of  operational 
“needs”  in  the  MOR  are  necessary  from  the  outset.  Reduced  to  basics: 


.  The  user  states  his  needs  and  the  architectural  developer  produces  to  those 
criteria,  or 

•  The  developer  uses  his  own  assumptions  to  prepare  an  architecture  within  which 
the  user  is  constrained,  regardless  of  the  operational  requirement. 

If  the  competing  contractor  teams  were  devising  candidate  architectures  that 
could  satisfy  a  common  MOR,  the  eventual  selection  process  could  start  from  a 
common  basis  of  understanding.  The  panel  can  not  determine  whether  this  spe¬ 
cific  process  of  definition  took  place  in  the  Phase  I  and  the  Phase  II  architecture 
development  projects.  It  appears,  however,  that  selected  contractor  teams  use 
Volume  .V  of  the  Fletcher  Report  as  their  “common  baseline”  in  the  absence  of  a 

specific  MOR. 


A.  Flexibility  in  Architectural  Development 

Weapons  technologies  evolve  in  response  to  an  adversary’s  potential  threats. 
So,  too,  does  the  architecture  for  the  SDI  BM/C3  system  depend  on  the  forecast 
threat  and  how  that  threat  evolves  many  years  ahead.  It  is  difficult  for  national 
intelligence-gathering  organizations  to  identify  a  range  of  future  threats  with  any- 
detailed  degree  of  accuracy.  Thus,  for  both  weaponry  and  the  supporting  BM/C  , 
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understanding  the  threat  becomes  an  evolutionary  process  that  is  subject  to  changes 
and  refinements  on  a  continuing  basis. 

b  a  process  where  the  threat  and  the  ability  of  future  ‘^.logies  to  cope 

i  4  i„  !+  :s  difficult  to  “freeze”  an  architecture  early  in 

atwwch'pro^am  wTthout  potentially  hindering  the  program’s  results.  SPeclfy'^ 
L^ctSotion  reduces  deveiopmental  costs  and  risk  * , 
aooroach.  The  specificity,  or  Wing”,  process,  however,  can  not  accommodate 
radical  changes  in  the  military  posture  of  the  defensive  forces  or  the  a  versary. 
combination  of  these  factors  leads  to  the  conclusion  that  there  must  be  an  in  eren 
ZX  in  the  architectural  development.  This  Senility  will  requires  close, 
relationship  between  the  eventual  user  and  the  architectural  developer. 

The  problems  that  a  BM/C3  system  faces  are  not  only  those ^C^thec- 
the  research  phase  and  forecasting  a  fully  deployed  system.  The  BM/C  architec 
turaTXX^r  must  also  consider  a  wide  range  of  options  for  deployment  W  th 
sT tea^Xum  -there  *  a  “pharo-in/phaserout”  cycle  of  new  weaponry  or  old. 
MU*  the  spaceborne  segments  alone  wUl  probably  encompa^  sev^ye^s. 
TW^fore  one  can  expect  to  have  various  transitional  phases  in  any 
i  nt  of  the  SDI  system  One  can  also  envision  an  evolutionary  change  in  the 

begins  its  initial  deployments  and  obsolete 

weapons  are  withdrawn  from  the  active  system’s  inventory. 

In  the  time  between  Initial  operational  capability  and  full  deployment  s  variety 
of  procedural  changes  would  occur  in  the  nation’s  strategic  command  snd ^  contro 
sysZ  The  BM/C’  system  for  SDI  must  necessarily  be  interoperable  with  other 
cCrol  that  the  strategic  forces  use.  Throughout  the  deployment  phase  the 
C’  systems  and  their  supporting  architectures  must  be  sensitive  to  unfor«een  h- 

nological  factor,  and  political  realities  at  international  ™£>’l  dl pi oymen 1 

architecture  and  the  BM/C3  system  to  support  an  operational  SDI  deployment 
must  be  designed  to  accommodate  the  changing  nature  of  force  deployments. 

One  should  recognise  from  th.  start  that  this  .yolution  requires ’ Master  degree 
of  human  intervention  to  control  residual  strategic  operational  fore* ** 
that  might  not  be  required  for  controlling  an  SDI  force  so ey. 
in  the  required  degree  of  man-machine  interface  carry  great  significance  due 
imperative  to  control  these  tremendously  destructive  forces. 

Because  SDI  shifts  strategic  weapons  from  an  offensive  to  a 
its  critics  and  proponents  have  commented  that  various  aspects  of  a  future  strategy 
defense  system  wUl  affect  national  policy,  military  doctrine,  and  operational/ pro¬ 
cedural  mechanisms  that  form  the  basis  for  the  battle  management. 
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The  term  “national  policy’  implies  a  consensus  that  represents  the  views  of 
broad  segments  of  the  American  public.  A  policy  of  this  kind  is  necessanly  more 
broadly  based  politically  than  are  the  goals  of  a  particular  political  admims 
tion.  Further,  national  policy  is  an  evolutionary  process.  That  is,  national  support 
changes  with  the  goals  of  a  revised  strategic  posture  for  the  United  States. 

Military  doctrine  encompasses  the  codified  body  of  knowledge  that  establishes, 
in  various  levels  of  specificity,  the  military  means  to  carry  out  the  national  policy. 
The  command  and  control  mechanisms  -  or  battle  management  -  and  the  opera- 
tional  military  process  must  be  responsive  to  the  changes  in  policy  and  doctrine. 

Thus,  the  eventual  political  approval  process  for  SDI  could  lead  to  alterations 
in  the  military  doctrine  employed  by  the  operational  forces.  There  cou  e  a  senes 
of  user-developer  interactions  to  ensure  that  the  evolving  architecture  meets  the 
evolving  threat  and  the  dictates  of  national  policy.  Such  an  iterative  process  would 
have  a  “trickle-down"  effect  on  the  operational  forces  and  the  BM/C  system  tha 
those  forces  use  at  the  lowest  echelons. 

The  considerations  outlined  previously  will  also  affect  the  design  criteria,  per¬ 
formance,  and  degree  of  simulation/ testing  necessary  to  ensure  “acceptable  levels 
of  compliance  with  the  program’s  operational  goals.  To  accomplish  this  broader 
task,  the  great  number  of  technical  factors  woven  throughout  the  program  would 
require  a  total  systems  concept  from  the  start. 


B.  Program  Consistency  and  Budgetary  Strategy 

Several  factors  create  the  inconsistency  of  funding  for  C3  programs  that  has 
long  been  a  problem  within  DoD.  Support  for  specific  programs  by  an  individual 
military  service  often  has  varied  yearly  and,  on  occasion,  has  borne  little  re  a- 
tionship  to  a  previously  agreed-upon  joint  position.  Another  factor  mvo  ves  e 
inherent  instability  of  assignments  of  individual  program  managers  and  their  staff 
superiors.  Also,  the  vagaries  of  the  annual  defense  and  federal  budget  processes 
create  budgetary  fluctuations.  Historically,  the  government  and  contractors  have 
underestimated  program  costs  for  both  hardware  and  software. 

C3  -  as  a  generic.item  in  DoD  -  has  enjoyed  relatively  large  increases  in  the  levels 
of  appropriated  funding’in  the  past  four  years.  Budgeting  is  now  at  a  level  where  any 
additional  increases,  even  for  SDI,  become  problematic.  The  SDI  apportionment  or 
BM/C3,  important  as  it  is,  shares  the  vulnerability  of  all  other  Defense  C3  programs 
to  congressional  fiscal  reductions  and  the  need  to  balance  major  budget  programs. 

Operating  within  the  DoD  Planning,  Programming,  and  Budgeting  System 
(PPBS),  the  creation  of  the  young  SDIO  caused  an  irregularity  among  more  estab¬ 
lished  and  “regularized"  means  of  funding.  The  highly  structured  budget  system 
of  DoD  requires  almost  full-time  work  of  some  members  of  the  military  services 
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and  defense  agencies.  The  SDIO  staff  is  too  small  to  continually 

attention  to  both  details  of  the  technical  research  programs  and  routine  S 

processes  that° permeate  Pentagon  life.  In  short,  SDIO  simply  does  not  have  the 

personnel  to  perform  requisite  tasks. 

If  SDIO  is  to  promptly  fund  and  award  research  contracts  on  ' 

and  accomplish  research  in  a  timely  manner,  the  budgeting  process  -with 
PPBS  aspects  -  must  become  more  “normalised”  for •  long-i term  fundi ng.  T  ^ 

DoD  must  formally  recognise  the  unique  functions  of  S  wi  1  services 

would  establish  and  enhance  relationships  among  the  individual  military  serv,  , 

the  Joint  Staff,  and  other  DoD  functions. 

Developing  such  a  normalization  process  will  require  innovative,  unique,  and 
specialised  chLges  regarding  the  relationship  of  SDIO,  its  funding  authorisations, 
and  the  military  services  -  the  product’s  ultimate  users. 

fiecommendetfon:  Establish  an  early  dialog  among  the  developers  of  the 
strategic  defense  system  architecture,  the  developers  of  the  battle  manag 
menTsystem^and  the  ultimate  users  of  the  system.  It  is  the  ultimate  users 
of  the  system  who  should  develop  the  military  doctrine. 
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m.  ARCHITECTURE 


The  Fletcher  Report  presents  a  model  architecture^  based  on  an  assumption 
of  each  sensor  and  weapon  having  all  situation  information  that  may  be  relevant 
to  its  function.  This  model  served  as  a  baseline  for  examining  the  computing  and 
communication  demands  of  a  strategic  defense.  The  Fletcher  Report  c  ear  y dis¬ 
tinguishes  between  the  role  of  such  idealized  architectural  models  and  practical 

imp  lenient  at  ions . 

The  development  and  characterization  of  practical  architectures  for  a  strategic 
defense  system  is  a  complex  endeavor.  The  “design  space"  of  possibilities  is  very 
large,  and  there  are  many  criteria  by  which  to  evaluate  a  given  architecture.  T 
following  criteria  are  fundamental: 


•  Performance:  There  is  no  simple  measure  of  the  performance  of  a  strategic 
defense  architecture,  in  that  it  must  be  designed  to  respond  to  many  different 
attack  scenarios.  Generally,  however,  the  number  and  fraction  of  warhea  s  in¬ 
tercepted  in  an  all-out  attack  is  a  useful  rough  measure  of  performance.  Other 
properties  of  an  architecture,  such  as  reliability,  durability,  robustness,  and  i- 
versity  contribute  to  its  performance.. 

•  Testability:  The  testability  of  an  architecture  can  be  measured  by  the  confidence 
with  which  one  can  determine  the  performance  of  a  deployed  system.  Because 
full-scale  tests  are  impossible,  just  as  they  would  be  for  the  strategic  offense,  the 
system  must  be  structured  in  a  way  that  allows  its  performance  to  be  inferred 
accurately  from  small-scale  tests. 


•  Cost:  The  cost  of  a  strategic  defense  system  is  of  obvious  relevance,  and  includes 
components  of  the  cost  of  developing,  building,  deploying,  and  maintaining  the 
system.  Although  the  cost  of  building  and  deploying  sensors  and  weapons  is 
expected  to  dominate  the  cost  of  a  deployed  system,  the  complexity  of  the  battle 
management  software  to  control  a  given  architecture  transcends  simpler  cost 
measures.  Excessively  complex  software  can  not  be  produced  at  any  cost. 

Earlier  this  year  there  were  10  contractor  studies  performed  in  “Phase  I”  of 
the  “System  Architecture  Key  Tradeoffs  Study".  Those  of  these  studies  that  the 
panel  has  reviewed  have  adhered  closely  to  the  Fletcher  Report.  In  particular,  the 

t  See  Volume  V  of  the  Fletcher  Report,  section  4.2,  for  a  discussion  of  the  utility 
and  limitations  of  this  model. 
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to  the  issues  of  software  complexity  and  testability. 

This  deficiency  in  the  Phae.  I  studies  ct  «e 

end  testing  requirements  ere  purely  to  control 

are  purely  academic. 

SDIO  must  not  assume  that  any  architecture  with  sufficient  sensors  and  weapons 
in  the  “aces  is  also  a  feasible  amhitecture,  i.s.,  one  that  can  be  ™pl«n  »t«l 

successfully.  oflnsors  and 

chitecture  presented  in  feasible  These  architectures  are  not 

software  and  fan  not  he  adequately  tested^  Hm-ver, “££££ 
SaT^r«  rrt- performance  and  cost  characteristics,  and  are 
testable. 

A.  Discussion 
1.  Coordination 

The  September  1985  issue  of  the  IEEE  Spectrum  is  largely  devoted  to  articles 
about  the  Strategic  Defense  Initiative.  The  discussion  of  battle  managemen  eg 
with  the  sentence: 

*A  Star  Wars  defense  system  would  need  to  respond  to  an  offensive  strike 
asasffiglemUsm,  Jrdinating  perhaps  millions  of  separate  actions  in  a 

schedule  timed  in  milliseconds.” 

The  panel  does  not  agree  with  this  statement,  particularly  with  the  concept  of  the 

commander-in-chief.  Instead,  responsibility  and  authority  is  delegated  in  the 
of  command. 

Similarly  a  strategic  defense  system  need  not  and  should  not  be  tightly  coordi- 
uated"^  lectures  that  the  pane,  regards  as  the  most  promising  are 
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those  that  are  organized  as  a  hierarchy  that  is  analogous  to  the  mUitaiy  chain 
command.  It  is  important  to  understand  that  coordination  a  not  absent  ”  !uch  » 
system.  Rather,  lower-level  tasks  are  delegated  to  and  localized  within  parts .of a 
system.  The  parts  can  in  turn  delegate  subtasks  to  their  putt.  The  battle  manage- 
ment  decisions  can  then  take  place  in  a  highly  decentralized  framework.  No  system 
part  within  such  a  hierarchy  (see  section  I.D)  needs  to  depend  on  millisecond-by- 
millisecond  detail  instructions  from  a  higher  authority. 

The  principle  that  can  be  applied  to  all  forms  of  coordination  within  the  spatially 
distributed  strategic  defense  system  is  this: 

Coordination  exhibits  the  property  that  the  time  that  can  be  allowed  to 
accomplish  the  coordination  increases  as  the  distances  involved  increase. 

The  fundamental  reason  for  this  property  is  that  the  targets  move  very  slowly 
compared  with  the  communication  signals.  For  example,  the  detai  so  w  a  may 
be  going  on  outside  of  the  “action  radius”  of  a  weapon  platform  is  information  that 
is  of  no  immediate  use  to  this  platform. 

Consider,  for  example,  a  small  battle  group  formed  from  several  sensor  and 
weapon  platforms  that  are  within  a  few  hundred  kilometers  of  each  other  and  a .  few 
hundred  kilometers  above  a  missile  launching  area  at  the  beginning  o  a  u  - 
attack.  The  battle  management  local  to  that  group  may  involve  the  exchange  of  a 
large  volume  of  information  about  the  location  of  the  missiles  as  viewed  fromeac 
sensor.  The  measurements  made  by  the  sensors  are  usefully  combined  or  “fused  in 
the  group’s  battle  management  system  in  order  to  provide  more  accurate  tracking 
of  the  missiles  than  could  be  accomplished  from  a  single  sensor.  This  information 
pertains  to  a  relatively  small  area,  and  might  be  updated  every  10ms  or  so. 

A  condensed  picture  of  the  local  situation  would  be  reported  for  purposes  of 
threat  assessment  to  higher  authorities  in  the  hierarchy.  The  higher-level  ba  e 
management  combines  the  threat  assessment  information  from  many  such  battle 
groups  and  from  high  altitude  sensors  to  present  a  condensed  threat  assessment  to 
the  command  authority.  Since  this  coordination  involves  the  collection  and  process¬ 
ing  of  information  -  fortunately  already  condensed  -  from  a  large  area,  one  cannot 
expect  it  to  be  updated  more  than  every  second  or  so. 

Another  type  of  coordination  that  could  occur  within  a  battle  group  is  the 
assignment  of  weapons  to  individual  missiles  during  the  boost  phase.  The  basic 
idea  is  to  optimize  the  assignment  based  on  weapon  and  missile  positions,  and 
also  to  avoid  expending  multiple  shots  at  one  missile  while  others  are  ignored. 
How  important  is  this  particular  form  of  coordination?  The  panel  has  studied  the 
possibility  that  weapon  platforms  attacking  missiles  during  the  boost  phase  choose 
their  targets  independently  based  only  on  local  sensor  data.  Results  of  a  preliminary 
analysis  and  simulations  indicate  that  this  decentralized  approach  would  require 
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w  tn  Hpstrov  the  same  number  of  targets  than 

SHssSSr.  t.-ttss?s 

and  decreased  testability. 

Coordination  in  the  midcourse  phase  involves  larger  areas,  more 
more  targets  The  optimisations  that  could  be  applied  are  more  complex,  but  there 
ZZXSZ.  to  perform  .here  computations  Tta  £ 

defense  again  involves  a  multitude  of  smaller  areas  and  the  need  for  faster  resp 

The  panel  has  concluded  that  the  coordination  required  for  °  '*  * 

defense  could  use  a  dec'entralired  and  loosely  coordinated  approach  to  battto  ““ 
agement.°This  approach  does  not  incur  a  significant  loss  in  P"™parei 
with  a  hypothetical  and  infeasible  model  of  a  perfectly  coordinated  defense. 

2.  Decentralized  Architectures 

There  are  many  critical  advantages  to  an  architecture  that  is  decentralised  to 
elements  that  are  capable  of  independent  action: 

.  Simplicity  This  type  of  architecture  can  reduce  the  complexity  of  the  battle 
management  software  by  eliminating  needless coordination.  S>nce  'h«appn.ach 

does  not  require  a  globally  consistent  data  ase  o  a  “g*  ’  h  d  li 

- -lotion  bandwidth  and  latency  requirements,  and  relaxes  scheduling 

demands. 

.  Testability:  An  arehivtur.  in  which  the  elements 

groups  -  are  capable  of  independent  action  is  testable.  The  ld“  a  s“p 
Test  each  independent  platform  or  group  separately.  If  each  works,  then  its 
XendeiT Slows  on.  to  infer  that  the  whole  will  work  akm  Tta  -  «•«* 
the  same  type  of  reasoning  that  allows  one  to  believe  that  our  highly  complex 
strategic  offensive  force  would  work  if  called  upon:  Each  missile,  once  launched, 

is  an  independent  entity. 

.  Evotvability:  System  architectures  that  are  not  highly  °n 

dination  are  more  easily  evolved  to  incorporate  new  technologies  or  to  respon 
“,r“h,  threat.  Such  architecture,  also  Vale”  well  from  sma^  o 
large-scale  deployments  without  requiring  increased  computing  capability  in 
each  element. 

.  Robustness:  Errors  in  on.  platform  or  battle  group  wof  dh“' aff«trf. 
effect*  If  one  system  part  experiences  an  error,  then  only  th  P 
With’ a  highly  centralized  architecture,  the  entire  system  could  be  adversely 

affected. 
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•  Diversity:  Decentralized  systems  also  gain  robustness  through  diversity.  Any 
realistic  plan  for  an  evolutionary  strategic  defense  must  allow  for  a  divers  y 
of  vendors  and  technologies  and  must  accommodate  continuous  changes  “ 
updates  to  the  system.  If  the  architecture  is  composed  of  elements  that  were 
built  and  maintained  by  different  vendors,  each  could  employ  different  hardware 
and  software  within  the  same  system  protocols.  Errors  or  vulnerabilities  m  one 
system  are  not  likely  to  be  duplicated  in  other  systems. 

•  Durability /Survivability:  The  loosely  coordinated  system  is  more  durable  in 
the  presence  of  hardware  upsets  and  more  survivable  in  the  event  of  active 
countermeasures  against  the  defense  system  itself.  For  example,  if  a i  platform 
loses  its  data  base  due  to  a  ffux  of  high-energy  neutrons  from  a  nearby  nuclear 
explosion,  unaffected  platforms  continue  to  function  while  the  affected  platform 
reconstructs  its  data  base  from  freshly  arriving  sensor  data. 

3.  Implementation  Issues 

Decentralized  system  architectures  raise  several  interesting  issues  that  the  panel 
has  considered  and  commends  to  the  attention  of  system  implementors. 

First,  there  must  not  be  a  loss  of  human  control  over  the  independent  groups. 

It  might  seem  that  the  decentralized  system  implies  a  loss  of  human  control  over 
an  “autonomous”  entity.  However,  it  can  be  made  as  difficult  for  a  single  battle 
group  within  a  hierarchy  to  obtain  weapoir  release  authorization  as  it  is  for  e 
entire  system.  The  independence  of  the  battle  groups  might  even  provide  greater 
flexibility.  For  example,  the  command  authority  could  authorize  only  some  of  the 
independent  groups  be  armed  in  order  to  match  the  defensive  level  to  the  type  of 

attack. 

Second,  coordination  and  communication  are  reduced  in  decentralized  architec¬ 
tures:  they  are  not  eliminated.  Someforms  of  coordination  are  sufficiently  impor  an 
to  system  performance  to  justify  their  inclusion,  even  if  they  are  quite  expensive  m 
computation  and  communication.  Consider,  for  example,  the  projection  of  ballistic 
trajectories  in  midcourse  and  assignment  of  priorities  to  targets  in  order  to  prevent 
any  single  area  from  receiving  a  high  concentration  of  RVs.  This  form  of  coordina¬ 
tion  appears  to  be  a  valuable  strategy  for  the  defense.  It  can  provide  useful  tracking 
information  for  the  terminal  defense,  and  substantially  reduce  the  total  number  of 
warheads  that  “leak”  through  the  defense.  This  form  of  coordination  is  difficult  to 
test  directly,  one  would  have  to  rely  on  simulations  to  test  this  software. 

Third,  the  decentralized  approach  might  appear  to  be  costly.  Since  the  costs 
of  the  sensors  and  weapons  so  thoroughly  dominate  the  cost  of  a  strategic  defense 
system,  it  could  be  argued  that  one  must  not  “waste”  shots;  hence,  the  need  for  tig 
coordination.  In  every  estimate  of  the  total  system  cost,  the  most  grandiose  estimate 


-26- 


of  the  software  is  less  than  a  few  percent  of  the  total  cost.  This  «ti^W  could  tempt 
designers  to  save  hardware  costs  by  writing  more  clever  and  complex  software^  i  n 
panel  cautions  that  SDIO  must  consistently  resist  such  temptations  The  p^  y 
to  software  development  must  be  baaed  on  minimizing  the  software  ditticu  y. 

the  United  States  could  end  up  with  a  -cheaper”  system  that 

simply  does  not  work. 

For  example  it  may  be  possible  to  design  architectures  that  use  abundant  com- 
puting  cycles  to  reduce  the  software's  complexity.  In  general, the  most 
part  of  software  stems  from  trying  to  optimize  its  Performance^ “ ' ‘“^d  Thet 
force”  algorithms  rather  than  complex,  special  case-laden  metho  ’ 

the  software  is  likely  to  be  more  reliable.  It  may  also  be  possible  to  use  additio 
computing  cycles  to  avoid  other  complexities.  For  example,  faster  s-Snsl  processing 
17be  able  to  simplify  the  amount  of  information  that  must  be  passed  from  one 
sensor  to  other  in  order  to  achieve  sensor  fusion. 

Finally,  the  panel  has  not  been  able  to  form  a  good  quantitative  mgument  on 
,h,  tradeoffs  between  the  number  of  platforms  and  their  size  and  tos^  Should^here 
be  40,000  platforms  each  weighing  100kg,  or  400  platforms  each  weighing  10  OOOkg 
or  something  in  between?  It  seems  intuitively  clear  that  survivability  is 
by  ^ploying  a  larger  number  of  smaller  platforms.  On.  could  m^e  the  radar 
croTsLionof  the  small  platforms  very  small,  but  one  can  not  effectively  hide 
objects  in  Earth  orbit  due  to  their  emission  of  «300”K  thermal  radiation  agains 
the  »3°K  sky  background.  The  presence  of  more  platforms  may  also  favorably  affec 
^ImfcfbTll^iTg  the  platforms  to  be  closer  to  the  targets.  Large  numbers  of 
^TXSlTTctaplr  to  manufacture.  SDIO  should  study  this  question. 

4.  Open  Systems 

Another  important  issue  to  which  any  architecture  must  attend  is  the  ability 
to  adapt  to  changes.  These  changes  may  be  driven  by  corrections  °r  by  responses 
to  possible  countermeasures.  Clearly,  future  enemy  countermeasures 
to  predict  with  great  confidence.  Also,  first-time  sensor  surprise  phenomena  are 
commonplace:  New  sensors  do  not  always  behave  initially  as  expected. 

The  panel  recommends  that  the  architecture  for  the  strategic  defense  system 
be  formulated  as  an  -open  system *  that  can  allow  the  rapid  insert  of  unanticipated 
new  components  and  modification  of  existing  pieces. 

SDIO  could  begin  with  the  design  of  a  core  of  communication  and  information 
exchange  protocols  and  build  the  rest  of  the  strategic  defense  system  around  this 
“reTthftway  adding  a  new  sensor  or  weapon  to  a  group  would  be  a  relatively 

straightforward  change  to  part  of  the  system. 

Designing  open  systems  is  still  very  much  a  research  topic.  One  can,  how- 
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ever,  find  the  more  rudimentary  concept  of  providing  a  framework  of  standardised 
hardware  and  software  interfaces  in  systems  ranging  from  personal  computers  to 
advanced  operating  systems.  This  approach  has,  with  remarkable  consistency,  been 
very  successful  when  applied  to  such  commercial  systems.  The  panel  «p«ts 
similar  advantages  are  possible  for  an  open  strategic  defense  architecture  and  there- 
fore  the  panel  recommends  that  SDIO  should  sponsor  research  into  the  design  of 

open  systems. 


B.  Recommendations 

The  panel  recommends  that  SDIO: 

•  Develop  a  decentralized  strategic  defense  architecture. 


•  Continue  Phase  I  as  an  ongoing  activity. 


Develop  the  battle  management  system  as  an  open  system 
insertion  of  new  assets  and  modification  of  existing  pieces, 
sponsor  research  into  the  design  of  open  systems. 


that  allows  rapid 
SDIO  should  also 


•  Study  architecture  tradeoffs  by  early  coupling  of  the  architecture  work  with  the 
development  of  battle  management  and  simulation. 


.C.  Summary 

The  most  important  point  that  the  panel  makes  is  that  in  evaluating  any  archi¬ 
tecture  for  SDI,  one  must  consider  both  the  ability  to  make  the  required  software 
work  and  the  ability  to  test  it.  An  architecture  that  can  not  be  tested  or  that  relies 
on  software  that  does  not  work  is  of  no  value.  This  issue  is  so  important  that  SDIQ 
must  be  prepared  to  make  a  variety  of  tradeoffs  among  all  elements  of  a  strategic 
defense  system  to  make  the  software  and  the  testing  tractable. 

Finally,  the  panel  stresses  that  a  time-driven  choice  for  a  specific  strategic  de¬ 
fense  architecture  does  not  exist.  The  design  space  is  vast,  and  a  great  deal  of  work 
remains  before  a  clear  choice  can  be  made.  Clearly,  SDIO  must  evaluate  archi¬ 
tectures  on  their  performance,  cost,  and  testability  before  selecting  the  preferred 
strategic  defense  architecture. 
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IV.  SIMULATION  AND  TESTING 


Simulation  has  in  recent  years  assumed  a  critically  i^ortant  rote  ^n  reseMch 
and  engineering  projects  “•*  possible  for  SD1  to  test 

the  possibUities  for  testing  a  «nxp'ete^trategic 

completely)  substitute  for  traditional  testing. 

In  addition  to  the  long-range  importance  of  simulation 

— 1 C2 

decision  will  be  made.  For  example. 

.  b  it  possible  to  design,  implement,  and  test  the  BM/C'softwareforthestrategic 
defense  system  so  that  it  will  achieve  the  necessary  level  of  performance  an 

reliability? 

.  Are  the  battle  management  strategies  embedded  in  the  BM/CJ  software  ade- 
quate  to  cope  with  possible/potential  attacks? 

Conclusive  answers  to  these  questions  require  that  the  simulation  facilities  have 
eanabilitv  of  modeling  the  components  of  the  strategic  defense  system,  an  i 
tteal^detaii.  These  component  include , the 

”f’ «"  "ics 

of  the  objects  the  generation  and  propagation  of  the  signals  and  communications 
tha^pass  between  them,  and  the  component's  internal  computations  and  resulting 

actions. 

The  simulation  facilities  must  also  have  the  ability  to  r replace  Simula adjunc¬ 
tions,  whether  hardware  or  software,  with  real  components,  for  simulat  on  val  dation 
and  for  testing  purposes.  This  technique  is  referred  to  as  in-line  testing.  Pr  P  y 
ta-ltae»sting  can  accelerate  engineering  development  by  allowing  the 
ZZ?*  y  «m  components  and  protores  into  a  realistic  system  environment 
ZT«t«  ing  in  early  tests  problems  that  would  by  traditional  methods  appear 
X  "®s«m  integration  phase.  In-line  testing  should 
deployed  assets  of  a  strategic  defense  system.  For  example,  one  could  test  the  ba 


management  functions  of  a  “battle  group”  by  communicating  simulated  data  to  the 
sensors  and  simulating  the  effects  of  weapons. 


The  advantage  of  simulation  over  testing  is  its  ability  to  consider  many  cases, 
including  situations  that  would  be  difflcult,  provocative,  expensive,  or  impossible 
to  duplicate  in  a  test.  The  advantage  of  testing  over  simulation  is  its  realism. 
The  panel  has  emphasized  elsewhere  in  this  report  the  necessity  of  structuring  the 
system  architecture  so  that  one  can  infer  the  performance  of  a  full-scale  deployment 
from  a  much  smaller-scale  test.  Simulation  in  conjunction  with  testing  has  a  similar 
purpose  but  Is  also  capable  of  modeling  the  system  operation  at  variable  levels  of 

detail. 


The  proposed  simulation  and  test  facilities  will  serve  to: 

•  Simulate  BM/C3  architectures  and  battle  management  strategies  to  determine 
their  performance  when  faced  with  various  attack  scenarios,  and  their  continued 
performance  (robustness)  in  the  face  of  failures  due  to  system  daws  (bugs)  or 
hostile  action.  Such  simulations  are  the  ideal  vehicle  with  which  to  study  system 
tradeoffs. 


•  Support  prototype  and  actual  BM/C3  software  to  provide  a  base  for  the  testing 
and  debugging  of  the  software  as  it  is  developed. 

•  Interface  with  real  weapons,  sensors,  and  communications  channels  to  support 
in-line  testing  of  the  strategic  defense  system*  prior  to  and  after  deployment. 

•  Provide  a  facility  for  testing  and  evaluating  ongoing  improvements  and  updates 
to  the  BM/C3  software. 

The  simulation  facilities  are  essential  for  the  designing,  coding,  and  debugging  of 
the  strategic  defense  battle  management  system  and  will  provide  an  important  part 
of  the  basis  for  the  system’s  credibility. 

This  chapter  describes  the  functional  requirements  of  simulation  and  testing  fa¬ 
cilities.  It  also  outlines  development  projects  needed  to  determine  and  meet  system 
requirements. 


A.  Discussion 


1.  Simulation  Facilities 

The  simulation  facilities  have  functions  that  require  operation  at  several  levels. 
Testing  and  debugging  the  strategic  defense  system  requires  a  simulation  that  runs 
with  great  detail  and  can  support  actual  battle  management  software  ^inter¬ 
faces  to  real  weapons,  sensors,  and  communications  platforms.  Evaluating  BM/C 
strategies  requires  rapid  but  less  detailed  simulations  of  large  numbers  of  battles. 
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We  expect  that  low-level  simulator*  used  for  sensors  and  weapons  development 
might  run  orders  of  magnitude  slower  than  real  time. 

The  mid-level  simulators  must  be  able  to  interface  with  other  simul,ttons^tem 
or  with  components  of  a  real  strategic  defense  system  to  permit  in-lin  t««mg.  The 
panel  envisions  one  or  more  of  the  mid-level  simulation  systems  as  distributed .  with 
parts  of  a  simulation  running  at  various  ground  sites  and  parts  running  on  p 
in  space.  Such  simulators  must  necessarily  run  in  real  tune. 

The  high-level  simulators  for  studying  BM/C1  strategies  could  reasonably  run 
very  much  faster  than  r6al  time. 

It  is  attractive  to  consider  multi-level  simulations  in  which  different  parts  of  a 
simluo"  different  levels  „  detail.  However,  this  ^  not  v^P- 
because  of  the  orders  of  magnitude  differences  m  speed. 
careful  abstraction  at  the  different  levels  to  produce  and  validate  models 

system  components. 

Simulation  efforts  should  cooperate  closely  with  activities  at  the  National  Test¬ 
bed  (NTB).  But  for  several  reasons,  NTB  should  not  be  the  only  simulation  facluy. 
First  simulation  is  too  vital  to  the  strategic  defense  effort  to  permit  a  monopoly 
that  would  be  implied  by  such  a  single  implementation.  Second,  comparison 
SSffiZ-  Simulation  facilities  for  purposes  of  =r-veri8«t.on  and 

validation,  is  essential.  Third,  a  centralized  implementation  at  NTB  would  Idtely 
lead  to  classification,  very  limited  access,  and  narrow  focus, -whidi  woul System's 
simulator’s  effectiveness  and  prevent  it  from  producing  confidence  in  the  sy 
functionality  and  reliability. 

Therefore,  the  panel  recommends  that  multiple  simulation  facilities  be  con¬ 
structed  for  testing  and  debugging  the  strategic  defense  system  and  for  evaluating 

BM/C*  strategies. 

Common  interfaces  should  be  used  so  that  a  simulator  of  one  type  can l  interact 
with  one  of  another  type  and,  if  needed,  could  be  interchangeable.  Each 
verify  and  update  the  other. 

Sensor  weapon,  and  communication  channel  interfaces  must  be  defined.  Simu¬ 
lation  systems  interfaces  also  must  be  defined  so  that  parts  of  the  strategic  defense 
system  can  be  simulated  independently  and  on  different  computer  systems  that  can 
be  developed  by  different  contractors. 

In  addition  to  the  common  interfaces  mentioned  previously,  the  various 
lators  rrrth.  same  abstractions  and  models  such  that  similar  results  could 
be  expected  when  similar  Input  is  given  to  different  simulators. 

The  coordination  among  the  various  simulation  activities  to  assure  the  com- 
monality  of  the  Interfaces,  protocols,  abstractions,  and  models  is  an  activity 
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must  be  performed  explicitly.  SDIO  should  recognize  the  coordination  task  of  the 
various  simulation  activities  as  an  explicit,  independent  activity. 

The  various  simulators  should  be  available  for  operation  over  a  computer  com- 
munication  network,  such  as  the  SDInet  discussed  in  Chapter  VH  (Communication), 
in  order  to  provide  easy  and  frequent  access  to  their  users. 

2.  Simulation  Verification  and  Validation 

Simulation  verification  ensures  that  the  simulation  system  meets  its  specification 
and  that  its  code  is  correct.  Simulation  vacation  ensures  that  the  simulation  meets 
the  user  requirements  and  corresponds  with  the  real  system  it  is  intended  to  model. 

SDIO  should  support  research  investigating  the  general  problem  of  simulation 
verification,  and  in  particular  the  actual  verification  and  validation  of  the  simulation 

development  for  SDI. 

Each  simulation  component  should  be  verified  and  validated  by  at  least  one 
independent  party.  The  panel  expects  that  the  construction  of  multiple  simulation 
and  test  systems  will  greatly  aid  the  verification  and  validation  process.  Cros  - 
comparisons  among  the  facilities  should  reveal  errors  in  the  systems  specification, 

design,  and  implementation. 

3.  Weapon,  Sensor,  and  Communication  Simulations 

The  simulation  of  each  weapon,  sensor,  and  communication  component  should 
start  out  as  a  high-level  representation  and  become  refined  in  the  level  of  detail  as 
the  actual  component  is  defined  and  developed.  Simulations  should  be  developed 
jointly  by  simulation  specialists  and  the  contractors  developing  the  actual  systems. 

The  sensor  simulators  should  access  the  battlefield  map  and  produce  a  partial 
and  distorted  map  that  depends  on  the  modeled  capabilities  of  the  simulated  sensor, 
such  as  the  detection  probability  as  a  function  of  range,  angle,  and  signature. 

The  weapon  simulators  should  access  the  battlefield  map  and  produce  hits  that 
depend  on  the  modeled  capabilities  of  the  simulated  weapons,  such  as  the  hit  prob¬ 
ability  as  a  function  of  range,  angle,  signature,  and  site  of  the  target. 

The  communication  simulators  should  deliver  messages  between  the  simulated 
sensors,  battle  managers,  and  weapons  according  to  the  modeled  capabilities  of  the 
communication  systems,  such  as  error  probability  as  a  function  of  range,  message 
length,  and  environmental  factors. 

4.  Battle  Management  Strategy  Evaluation  and  Testing 

The  primary  function  of  the  BM/C3  architecture  simulator  is  to  evaluate  differ¬ 
ent  strategic  defense  system  architectures  and  various  battle  management  strategies 
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against  a  variety  of  attack  scenarios.  SDIO  should  implement  early  the  high-level 
,hP.h>'«  thafare  needed  for  the  evaluation  of  battla  management  architectures 
and  strategies  under  a  large  set  of  attack  scenarios. 

The  adequacy  of  the  battle  management  architecture  and  strategies  will  be  heav- 
Ur  influenced*1 by  the  thoroughness  of  the  attack  tests.  The  attack  senary  shouW 
t  implemented  in  whatever  level  of  detail  that  is  needed  to  model  anfc.pa.ed 

enemy  actions.  ,  , 

An  important  task  of  the  simulation  is  to  intellect  various  errors  into 

_ I,  system  and  to  simulate  failures  and  loss  of  components  m  order  to 

"S  ^stl's  ability  to  cope  with  such  problems.  NASA’s  experience  ,n  using 
“trouble-simulators”  has  proved  itself  most  valuable. 

In  general,  throughout  all  the  software  development  SDIO  should  insist  that 
each  software  delivery  be  accompanied  by  a  plan  for  testing  to  verify  that  it  meets 
ttTU—  -h  tha,  it  JL  b«  retested  whenever  Ganges « • 
it  or  to  its  environment,  whether  they  are  expected  to  mfluence  tor  not^  The  tes 
Dlan  should  cover  both  the  pre-  and  the  post-deployment  (  rn-line  )  testing,  and 
the  ways  to  verify  that  the  actual  implementation  match  the  prototype  simulation. 

B.  Recommendations 

The  panel  recommends  that  SDIO: 

.  Construct  several  distribute  and  diverse  but  centrally^ootdinated  simulators 
at  several  levels  for  testing  and  debugging  the  strategic  defense  system  and  eval- 
ua^  BM/C’  strategies.  Make  the  simulator,  available  for  use  over  computer 

communication  networks, 

.  Support  general  and  speciflc  research  in  simulation  verification  and  validation. 

.  Develop  simulations  of  weapon,  sensor,  and  communication  systems  through 
jointeffortswith  ,h.  developers  of  these  systems,  and  validate  the  abstractions 

of  the  various  system  components. 

•  Implement  early  high-level  simulators  that  permit  the  evaluation  of  battle  man¬ 
agement  architectures  and  strategies  under  a  wide  variety  of  attack  scenarios, 
aid  couple  them  early  to  the  system  architecture  and  battle  management  wo  . 
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C.  Summary 


The  strategic  defense  system  requires  simulators  at  several  levels:  for  archie 
tectural  studies,  for  battle  management  evaluation,  for  software  development  aud 
method  testing,  and  for  in-line  testing.  Interoperability  must  be  maintained  among 

the  various  simulators. 

Activities  at  the  software  simulation  facilities  will  often  be  at  the  state  of  the 
art  Both  fundamental  research  and  development  activities  should  be  pursued. 


For  the  architectural  simulation  studies,  it  is  very  important  that  SDIO  de¬ 
vote  substantial  resources  to  “red  teams”  that  devise  attack  scenarios.  The  panel 
appreciates  that  SDIO  has  already  decided  to  do  that. 
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V.  SOFTWARE 


Th.  P-1 1-  — T  f  “fX- ! ^ 

0Prn'|f0tl/toSm  Th«e  are^exploratory  development  projects  that  the  panel 
cally  related  to  SDI.  These  *  nr„  ■  architectures  for  the  battle 

l^ns" 

d^  ^ 

portant  that  those  who  will  manage  software  resear 
its  results  understand  its  limitations. 

"^d*  C^aP  j*f  P^  t^b^itle^^agements'oftware  and^h^te^rwlo^that  would 
ter  understandmg  of  the  battle  management.  technical  discussions  about 

r.;p^r—  ^z:ztjz  *  ^  -  -  *** 

software.  It  is  not  a  design  document. 

The  contents  of  this  chapter  are  derived  trim  the  panel’s  discussions  of  the 
following  basic  questions: 

.  What  possible  battle  management  system  architectures  are  the  most  feasible 
candidates  for  successful,  dependable  implementation. 

.  How  can  one  assess  the  likelihood  of  a  candidate  architecture  for  successful, 
dependable  implementation? 

.  What  conceivable  advances  in  software  research  would  make  a  difference  in  a 
battle  management  system’s  implementation? 

.  How  does  one  evaluate  whether  these  advances  wiU  make  a  difference? 

The  panel  has  concluded  that  feasible  system  architectures  exist.  As  discu»ed 
in  Chapter  HI  (Architecture),  it  is  possible  to  build.a  trustworthy  strategy  defense 

system  based  on: 

.  Choosing  simple,  even  if  suboptimal,  designs,  since  their  behavior  is  more  pre- 
dictable  over  a  wide  variety  of  circumstances. 
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•  Using  highly  decentralized  designs  so  that  testing  of  a  relatively  small  part  of 
the  system  would  provide  evidence  from  which  to  infer  the  performance  of  the 

entire  system. 

•  Using,  at  several  levels  of  the  system  design,  a  diversity  of  design  approaches 
and  implementations,  so  that  an  error  or  other  vulnerability  in  one  component 
is  not  repeated  in  all. 

The  panel  advocates  an  open  system  approach  to  the  design  of  the  battle 
management  software.  Open  systems  are  characterized  by  a  concurrent,  message- 
oriented  programming  model  and  narrow  semantic  interfaces  between  modules.  Ex¬ 
isting  open  systems  have  several  properties  that  would  be  desirable  for  the  battle 
management  software:  It  is  easy  to  add  or  replace  software  modules.  Often  they 
are  robust  under  a  wide  range  of  possible  subsystem  failures. 

A.  Discussion 

1.  Exploratory  Development 


The  Brooks  Law  of  Prototyping f: 
“Plan  to  throw  one  away;  you  will,  anyhow”. 


The  key  software-related  question  is  how  to  assess  the  feasibility  of  the  soft¬ 
ware  for  a  given  battle  management  system  architecture.  There  are  no  analytical 
methods  that  can  answer  that  question.  The  only  approach  available  is  to  propose 
a  range  of  possible  system  architectures  and  assess,  as  systematically  as  possible, 
their  effectiveness  and  dependability. 

To  this  end,  the  panel  recommends  that  SDIO  initiate  the  construction  of  several 
prototype  battle  management  software  systems.  These  exploratory  development 
efforts  are  intended  to  probe  the  battle  management  software  design  space.  Ideally, 
a  quite  diverse  set  of  design  approaches  will  be  employed,  including  a  variety  of 
open  system  designs. 

SDIO’s  selection  criteria  for  these  projects,  and  furthermore  its  evaluation  cri¬ 
teria,  to  be  repeatedly  applied  in  increasing  detail  throughout  the  lifetimes  of  the 

t  Frederick  P.  Brooks,  Jr.,  The  Mythical  Man-Month:  Essays  on  Software  Engi¬ 
neering,  Addison- Wesley,  1974.  In  the  paragraph  introducing  this  piece  of  time- 
honored  advice:  “The  management  question,  therefore,  is  not  whether  to  build  a 
pilot  system  and  throw  it  away.  You  will  do  that.  The  only  question  is  whether  to 
plan  in  advance  to  build  a  throwaway,  or  to  promise  to  deliver  the  throwaway  to 
customers.” 


-36- 


projects,  should  be  those  criteria  defined  in  Chapter  in  (Architecture).  Perf°r" 
mance,  cost,  and  testability.  SDIO’s  means  for  mcteasingly  ^ed  eimluatmn 
should  be  the  simulation  system  described  in  Chapter  IV  (Simula  ion), 
longing  requirement  on  the  simulation  system  that  it  be  capable  of  simulating  both 
th«  «ecuL  of  these  prototype,  and  the  scenarios  against  which  they  are  tested, 

and  at  increasing  levels  of  detail. 

These  battle  management  prototyping  project,  should  start  out 
at  about  the  25  man-year  level.  Initially,  the  project,  could  work  with 
or  simulated  approximations  of  the  sensor  and  weapon  characteristics.  Each  P™ 
should  be  capable  of  being  expanded  to  a  much  larger  scale  exploratory  deve  op- 
ment.  As  the  prototype  battle  management  systems  increase  in  size  and  capability, 
the  level  of  realism  and  detail  in  the  simulations  would  be  increased. 

Since  the  strategic  defense  system  wUl  be  distributed  among  many  assets  the 
battle  management  prototypes  should,  from  their  very  beginning,  be  designed  for 
operation  over  a  computer  communication  network. 

If  more  than  one  prototype  battle  management  system  were  deveioped  int o  a 
system  ready  for  deployment,  all  the  better.  This  outcome  would  be i  consis tent  with 
the  panel’s  philosophy  of  diversity  and  decentralization.  Still,  the  ability  nltunatc  y 
to  expand  a  prototype  to  the  development  of  a  deployable  system  should  be  treated 
as  a  goal  but  not  as  an  inevitable  outcome.  This  goal  prevents  ignoring  pro 
that  a  serious  development  might  have  to  face.  Furthermore,  this  goal  provides  »  • 
criterion  for  measuring  the  progress  of  each  project:  how  close  they  got  to  the  finish 
line  (as  opposed  to  how  far  they  got  from  the  start). 

Contractors  should  be  free  to  choose  their  own  development  environments 
methods,  and  design  approaches.  They  should  be  encouraged  to  experiment  with 
new  tools  and  techniques  and  with  unorthodox  structuring  of  the  development  or- 
ganization,  except  for  the  requirement  that  such  experiments  be  instrumented  as 

carefully  as  possible. 

It  appears  that  the  misconceptions  of  some  software  researchers  complement 
the  factual  knowledge  of  software  development  practitioners,  and  vice  versa.  One 
misconception  that  each  shares,  however,  is  a  belief  in  the  reality  of  the  a  e> 
fall  diagram" ,  the  portrayal  of  a  software  development  project  proceeding  smoo  y 
and  unidirectionally  from  requirements  specification  to  design  specification  to  cod- 
ing,  testing,  and  delivery.  The  truth  is  that  these  steps  can,  and  often  do,  feed 
back  into  any  of  their  predecessors.  In  particular,  the  basic  adequacy  of  a  sys¬ 
tem  design  is  determined  through  a  wide  variety  of  formal  and  informal  feedback 
mechanisms:  interactions  between  customer  and  implemented  design  walkthroughs, 
independent  validation  teams,  simulation,  testing,  and  operational  experience.  Ac¬ 
cordingly,  SDIO  should  consciously  attempt  to  exploit  the  potential  informative 
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power  of  these  feedback  mechanisms  while  exploring  possible  software  systein 
chitectures.  SDIO  should  be  as  prepared  to  start  new  projects  at  square  one  as 
it  is  to  expand  existing  ones.  This  approach  allows  the  insights  obtained  previous  y 
to  be  taken  into  account.  An  already-contracted  project  might  even  be  allowed  to 
start  over.  SDIO  needs  to  encourage  feedback  of  the  form,  “Our  first  approac 
didn’t  work” ,  or  “The  problem  you  asked  me  to  solve  turned  out  to  be  ill-pose  . 

SDIO  should  structure  this  prototyping  program  around  two  major  goals:  the 
assessment  of  the  feasibility  of  a  range  of  possible  battle  management  system  arc  i- 
tectures  and  the  establishment  of  the  specifications  of  the  system.  There  is  a  tradeoff 
between  the  effectiveness  of  a  strategic  defense  and  the  complexity  and  interdepen¬ 
dence  of  its  software.  Software  that  tightly  coordinates  the  actions  of ^every  Platf°™ 
to  insure  optimal  use  of  the  weapons  would  be  relatively  fragile  and  difficult  to  test. 
If  the  system  can  not  be  tested  convincingly,  the  defense’s  effectiveness  wi  never  e 
any  other  than  hypothetical.  Simulations  can  provide  approximate  measures  of  the 
effectiveness  of  prototype  software  architectures;  at  the  same  time  their  tes  a  1 1  y 
and  robustness  under  many  different  conditions  should  be  estimated. 


Complete  and  precise  specifications  of  the  requirements  are  vital  to  the  devel¬ 
opment  of  software.  The  prototypes  are  attempts  to  state  the  specification  of  this 
system.  This  is  the  concept  that  is  behind  the  emphasis  on  iteration  and  feedback 
in  the  prototyping  program:  If  the  specification  (prototype  system)  is  found  to  be 
erroneous  or  incomplete,  it  can  be  revised. 


The  panel  sees  this  set  of  projects  as  an  experimental,  exploratory  effort  to 
better  determine  the  most  feasible  battle  management  system  design  approaches. 
Therefore,  the  procurement  should  be  treated  more  like  a  research  contract  than 
as  a  development  contract.  The  government  does  not  know  exactly  what  it  wants, 
research  will  determine  what  it  needs. 


These  projects  may  expect  to  produce  as  deliverables  both  the  prototype  battle 
management  software  and  precise  definitions  of  the  formulation  of  the  system  in 
terms  of  modules  and  the  interface  protocols  among  them.  Unbiased  critiques  of 
each  design  approach  should  also  be  available  to  the  government.  Because  of  the 
unconventional  character  of  the  deliverables,  contracting  of  these  projects  mus  e 
executed  by  creative,  flexible,  and  somewhat  technically  sophisticated  people,  f  o 
everyone  involved  in  DoD  procurement  fits  that  description. 


2.  Basic  Research  Topics 

The  previous  section  is  the  “development"  part  of  the  panel’s  recommendations 
for  software  research  and  development  in  support  of  the  battle  management  system. 
What  follows  is  a  list  of  research  topics  selected  on  the  basis  of  their  chances  o  im¬ 
proving  strategic  defense  software  productivity  and  the  quality  of  the  end  product. 
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This  list  should  not  b«  interpreted  as  exhaustive  or  all-inclusive. 

The  distinction  between  research  and  development  is,  however,  difficult  to  make. 
There  are  several  examples  from  computer  science  history  where  clever pricks  m- 
vented  by  system  developers  in  the  course  of  a  development :  project  were  ‘h« 
tion  for  subsequent  fundamental  insights  into  that  type  of  design  problem.  A  bet 
understanding  of  the  battle  management  system's  basic  structuring  nnght  emerge 
tom  attempts  to  construct  prototypes,  just  as  experiences  tom 
writing  projects  fed  back  into  the  academic  community  and  led  to  3U<*  a  cle* 
understanding  of  compilation  that  modem  compilers  are,  generally  speaking,  all 
structured  in  the  same  way.  It  wffi  be  important  that  results  be i  shared 1  between  he 
prototype  system  developers  and  software  researchers  investigating  the  following 

topics. 

a.  Massive  Computing  Power  for  Software  Development 

The  panel  recommends  that  SDIO  support  research  on  how  software  develop¬ 
ment  pr^uctivity  would  benefit  tom  the  availability  of  massive  computing  power 
in  the  development  environment. 

The  use  of  supercomputers  -  high  speed  computers  that  may  or  may  not  re- 
semble  the  current  high  speed  scientific  computers  -  may  allow  software  Ampere 
to  create  new  tools  and  techniques.  For  example,  rt  may  be  possible  to  build lima 
higher  quality  debugging  environments  or  to  support  much  more  detaded  sem^ 
checkers  than  are  currently  available.  Another  interesting  possibility  is  to  explo 
real-time  animation  of  algorithms.  Researchers  have  already  demonstrated  that 
such  graphic  support  of  algorithm  development  is  a  very  powerful  technique.  The 
panel  expects  that  these  and  other  innovations  may  be  possible  if  supercompu 
are  available  to  software  developers. 

The  panel  recommends  that  this  research  program  begin  with  many  small  stud- 
ies.  These  studies  should  determine  in  finer  detail  the  possible  uses  and  benefits 
of  supercomputers  for  software  development.  If  these  studies  produce  Pr°^mg 
results,  then  the  use  of  supercomputers  for  would  be  justified  for  strategic  defens 

software  development  projects. 
b.  Software  Testing 

The  art  of  software  testing  amounts  to  a  search  for  good  compromises.  The 
range  of  possible  inputs  to  any  useful  program  is  too  large  for  the  program  o  e 
'  tested  exhaustively.  Innovative  approaches  might  be  found  for  selecting  test  sets  n 
such  a  way  that  they  “cover”  large  sets  of  possible  inputs  and  all  possible  beha 
(“branches”).  Ways  to  exploit  high  computing  speed  in  the  testing  environment 
would  be  of  interest.  In  particular,  the  panel  recommends  the  investigation  of 
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testing*  methods  and  tools  that  could  be  an  integral  part  of  a  software  development 
environment,  enabling  a  system  to  be  tested  at  all  levels  of  its  structural  hierarchy 
and  throughout  the  development  process. 

c.  Software  for  Reliable  Systems 

Software  engineering  researchers  have  perhaps  been  overly  concerned  with _Snd- 
ing  rigorous  mathematical  approaches  to  the  design  and  analysis  of  software.  These 
approaches  are  intended  to  assure  that  the  software  is  flawless.  The  panel  rec¬ 
ommends  that  SDIO  place  considerable  emphasis  on  the  invention,  reflnemen  , 
evaluation  of  software  design  techniques  that  would  allow  computing  functions 
be  performed  usefully  despite  hardware  faults  or  software  errors. 

Writing  software  for  computers  designed  to  tolerate  hardware  faults  is  currently 
a  complex  and  difficult  task.  A  combination  of  new  architectures  and  new  program¬ 
ming  techniques  might  make  it  easier  to  program  fault-tolerant  hardware. 

A  few  approaches  to  developing  software  that  can  override  or  compensate  for 
errors  have  been  proposed.  One  example  is  “iV-version”  programming,  or  design 
diversity” ,  in  which  several  programming  teams  write  a  program  to  the  same  spec¬ 
ification.  The  programs  are  run  together,  with  some  decision  procedure  selecting 
the  “correct  answer”  from  among  their  outputs.  Larger  experiments  than  have 
previously  been  feasible  would  contribute  to  the  evaluation  of  this  approach.  Ex-  . 
animations  of  the  likelihood  of  .highly  correlated  programmer  errors  should  also  be 
undertaken,  since  such  a  phenomenon  would  argue  against  the  use  of  the  technique. 

Other  approaches  entail  techniques  or  paradigms  in  which  a  software  module 
attempts  to  detect,  correct,  or  protect  itself  from  errors  occurring  in  different  mod¬ 
ules.  Watchdog  processes,  data  structure  audits,  and  recovery  blocks  fall  in 
category.  Two  additional  run-time  techniques  are  discussed  below. 

All  such  software  error-masking  approaches  are  computationally  demanding.  It 
is  important  to  understand  the  hardware  and  real-time  tradeoffs  involved  in  then 

use. 


c.l  Runtime  Checking 

It  may  be  advantageous  to  employ  more  extensive  runtime  checking  of  program 
execution  in  a  battle  management  system  than  is  used  in  common  computing  prac¬ 
tice,  even  if  it  requires  abundant  computing  power.  Such  runtime  checking  cou 
detect  and  sometimes  correct  programming  errors.  If  research  shows  that  such 
techniques  are  useful  for  battle  management  computations,  they  could  be  used  se¬ 
lectively  in  a  deployed  system.  Critical  computations  such  as  weapons  release  could 
be  implemented  in  this  “ultraconservative”  scheme,  while  noncritical  computations 
such  as  an  antenna-pointing  schedule  could  be  implemented  conventionally. 
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A  simple  example  of  a  useful  runtime  test  is  to  check  bounds  on  values  assigned 
to  variables.  Bounds  checking  is  commonly  used  for  array  >ni>ces;one  couW  also 
place  bounds  on  the  values  of  physical  quantities  to  enforce  a  s  y  erkal 

results  of  a  computation.  Another  example  of  runtime  checkin«  *  Quantities 

values  with  their  physical  units.  An  attempt  to  perform  an  addition  < **££££ 

CTd  with  different  physical  units  -  such  as  meters  and  grams  - 

an^  flagged  as  a  fatal  error.  An  attempt  to  add  quantises  expressed  in 

a  Quantity  expressed  in  nautical  miles  would  result  m  an  error  being  gg 

a  conversionTutomatically  performed.  These  examples  are  a  s,mple 

of  a  type  of  runtime  checking  that  is  already  performed  by  many  programming 

systems. 

c.2  Probabilistic  Techniques 

Decisions  based  on  probability  distributions  rather  than  on  a  single  item  of 
informationprcnride  a  control  on  the  extent  to  which  single  faults  or  programming 
errors  could  otherwise  propagate  to  corrupt  the  reliability  and  £ 

battle  management  system.  As  counterintuitive  as  it  may  seem  that  the  explic 
use  of  probabilistic  measures  could  increase  the  reliability  of  a  battle  managemen 
system,  the  panel  suggests  that  research  in  such  disciplines  may  well  prove 

fruitful..  ^ 

For  example,  critical  data  items  could  be  represented  not  just  “ !  s“*1‘ 
bers,  but  with  associated  probability  density  functions.  These  pwbnb'hty  density 
functions  could  be  represented  very  simply  with  “error  ars  on  a  »  , . 

precise  functional  representations  if  the  reliability  of  the  data  could  be  estimated  in 

this  way. 

In  combining  data  from  several  sensors,  one  could  weight  the  data  from 
different  sensors  according  to  their  reliability.  A  single  specific  number  represent  ng 
fat^^Sd  -  for  instance,  600  -  is  much  less  valuable  than  a  count  represented 
as  600±400.  Such  a  large  error  might  result  if  there  were  discrepancies between 
multiple  sensors,  and  would  cast  doubt  on  the  threat  assessment.  On  the  other 
hand's  count  of  600±4,  which  could  occur  only  if  there  were  substantial  agreement 
irTseverai  independent  assessments,  could  provide  a  high  confidence  level  for  a 
decision  to  activate  the  defense. 

At  a  higher  level,  modules  should  assess  the  credibility  of  each  other,  and  share 
this  credibility  measure  with  other  modules.  This  sharing  may  help  the  sys  em 
*  a  wt;,  to  detect  malfunction  of  some  components,  and  take  a  corrective  ac  ion 
such  as  instructing  the  malfunctioning  unit  to  “reboot”  itself,  or  suggesting  to  other 
units  to  ignore  the  malfunctioning  one. 
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c.3  Verification  and  Other  Mathematical  Proof  Techniques 

The  panel  does  not  recommend  abandoning  formal  techniques.  To  the  contrary, 
the  panel  encourages  SDIO  to  apply  them  as  appropriate,  but  wishes  to  caution 
SDIO  on  the  limitations  of  their  use.  Mathematical  proof  techniques  successfully 
applied  to  certain  very  critical  modules  or  protocols  would  increase  confidence  in 
programs.  The  codes  concerned  with  weapons  release  and  with  communication 
security  are  candidates  for  such  verification,  since  they  are  obviously  critical  and 
possibly  meet  the  other  criteria  as  well.  In  keeping  with  the  mam  theme  of  this 
report,  the  panel  suggests  that  the  ability  to  verify  these  important  modules  is  not 
as  vital  to  establishing  their  trustworthiness  as  is  defining  them,  from  the  start,  to 
be  as  simple  and  straightforward  in  function  as  possible. 

d.  Specification  Systems 

A  clear,  precise  specification  of  a  software  design  is  crucial.  Several  different 
notations  for  specifying  software  exist.  A  few  are  commercial  products;  others  are  in 
the  research  stage.  The  panel  recommends  research  support  for  that  class  of  specifi¬ 
cation  languages  intended  to  serve  as  more  than  just  an  independent,  documentary 
description  of  the  software  design. 

One  class  of  specification  languages  is  those  designed  so  that  programs  written 
in  them  can  be  iteratively  refined.  As  successive  levels  of  detail  are  added,  the 
programmer  has  strong  assurance  that  the  semantics  of  the  more  detailed  repre¬ 
sentation  match  those  of  the  previous  iteration.  Another  class  -  one  that  has  a 
large  intersection  with  the  first  -  is  composed  of  specification  languages  designed 
to  be  executable.  An  executable  specification  language  offers  several  advantages. 
It  forces  the  specifier  to  be  precise  and  to  avoid  ambiguity.  It  ties  in  closely  wit 
concepts  of  simulation  and  testing  at  every  level  of  refinement.  It  would  be  an  asse 
to  the  iterative,  exploratory  style  we  prescribe  for  the  battle  management  software 
development  projects  discussed  previously.  Research  prototypes  in  this  class  exist, 
but  are  presently  limited  in  usefulness.  They  are  often  slow  to  execute,  their  ab¬ 
struse  mathematical  notations  make  them  difficult  to  use,  and  they  are  unable  to 
express  some  types  of  software  requirements,  such  as  real-time  constraints. 
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e.  Parallel ,  Concurrent,  and  Distributed  Computing t 

Parallel  computing  is  a  necessary  direction  for  SDIO  to  take  in  the  realm  of  al¬ 
gorithmically  specialised  processor  arrays  for  signal  and  low-level  mage  processing. 

The  question  is  open,  however,  as  to  the  extent  to  which  more  ««erai-purp«e 
programmable  concurrent  machines  could  be  of  use  for  the  rapid  «ecut.on , of 
Lei  less  regularly  structured  battle  management  functions.  Small-  to  medium 
scale’ concurrent  computers  have  recently  become  commercially  available, “  “ 
eral  large-scale  experimental  prototypes  are  being  developed  However,  the  ability 
to  exploit  their  speed  over  a  broad  range  of  applications  lags  behind. 

SDIO  should  establish  centers  for  studying  algorithmic,  compilation  and  oper¬ 
ating  s^emles  in  the  context  of  programmable  concurrent  computer  s^ 

with  the  potential  of  having  fairly  general  application  domams.  MulUprocessor 
•cated  at  these  centers  should  be  available  to  SDIO  contractors  for  experimentation 
via  remote  access,  as  described  in  Chapter  VII  (Communication). 

f.  Organizational  Issues 

The  advent  of  networks  of  computer  workstations,  precise  specification  lan- 
-..p.,  and  other  components  of  advanced  software  development,  creates  f 
sibilitv  of  structuring  software  development  teams  in  entirely  new  ways.  Compu 
netwcdlur cansuppoH  distributed  development  of  software,  unlike  the  more — 
^geographically  colocated  efforts.  A  'cottage  industry”  of  snudl ,  mfoma^y 
organiradiroup.  could  conceivably  make  software  changes  easier  “d,f“  " 
avoiding  mistakes.  One  or  two  carefully  designed  experiments  with  r^dically  s^‘ 
tured  software  development  teams  might  be  a  good  choice.  It  might  e  wor 
to  conduct  a  historical  study  of  a  large  military  software  system  develoP^ent  pr°^ 
to  assess  the  technical,  managerial,  and  organizational  aspects  of  its  success  or  fail 

ure. 

g.  Exploratory  Programming 

SDIO  might  take  a  look  at  which  environments  enable  programmers  to  be  most 
productive.  Programmers  with  access  to  high-speed,  tool-nch  awmonmenu  h 
created  a  style  of  program  development  that  seems  to  be  based  on  an  attitude 
S-'UJ  make  programming  at  all  ieveb  to  be  less  “tensive^ 
Programmers  seem  to  feel  ftee  to  do  things  that  in  previous  environments  would 

f  These  terms  are  often  used  interchangeably.  To  the  extent  that  ^e  make  a 
distinction,  we  use  parallel  to  suggest  “lockstep’’  actions  as  in  a  P^lJdde^ 
or  SIMD  computer;  concurrent  to  suggest  partial  mdependenc  ’  ,  , 

MIMD  computer,  and  distributed  to  suggest  that  the  distribution  of  control  and 
data  represents  a  substantial  cost  in  comparison  with  computation. 
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be  prohibitively  expensive,  such  as  tearing  a  program  apart  and  PUtUngtback 
together  in  a  new  structure.  It  might  be  worthwhile  to  determine  and  study  th 
factors  that  support  rapid  prototyping  and  this  exploratory  style  of  programming. 
The  goal  of  the  studies  would  be  to  determine  how  the  programming  style  and  the 
powerful  environments  can  best  be  exploited. 

h.  Software  Maintenance  and  Reuse 

•Maintenance”  refers  to  the  continuing  process  of  changing  a  software  system 
while  it  is  in  service.  Belated  discovery  of  errors  and  omissions  dictate  £” 
the  code  of  a  delivered  system.  Maintenance  accounts  for  a  significant  fract  on  of 
the  overall  cost  of  a  software  system.  A  standard  rule  of  thumb  a  to  estimate  the 
maintenance  cost  share  at  70  percent.  A  deployed  battle  engagement  system  would 
undoubtedly  require  a  substantial  software  maintenance  effort.  The  panel  exp 
that  the  system  would  be  continually  tested  before,  during,  and  after  deployment, 
and  that  this  testing  would  expose  system  bugs  and  inadequacies. 

Introduction  of  new  technologies  into  the  defense  system  and  responses  to  newly 
discovered  countermeasures  or  threats  will  require  updates  to  software  that  is  e- 
yond  what  is  implied  by  the  term  “maintenance”.  New  versions  of  a  battle  manage- 
ment  system,  involving  the  reuse  of  substantial  portions  of  previous  versions,  will 
be  produced  at  regular  intervals. 

It  is  as  important  to  apply  the  same  rigorous  discipline  to  the  design,  verifica¬ 
tion,  and  testing  of  new  versions  of  a  system  as  it  is  to  the  original  implementation. 

Both  maintenance  and  reuse  are  simplified  by  a  careful  choice  of  the  way  in  which 
the  system  is  partitioned  into  modules.  However,  there  has  been  little  research  on 
tools  for  modifying  software  systems.  The  panel  proposes  that  attention  be  given 
to  the  question  of  what  methods  and  tools  might  be  applied  not  only  at  design 
time,  but  throughout  the  development  process.  Methods  might  be  develope  o 
determine  and  monitor  the  modules  of  code  that  reflect  each  system  requirement 
easing  the  job  of  accommodating  a  change  to  that  requirement  even  if  the  affected 
code  is  dispersed  rather  than  isolated, 

3.  On  the  Nature  and  Limitations  of  Software  Research 


a.  Software  research  can  not  be  expected  to  make  radical  advances 

The  panel  is  certain  that  no  technological  means  will  be  as  vital  to  the  suc¬ 
cessful  development  of  the  battle  management  software  than  the  choice  of  the  rig  t 
end.  SDIO  must  not  undertake  an  arbitrarily  difficult  software  development  task, 
expecting  a  breakthrough  in  software  research  to  happen  in  time  to  save  the  day. 
Finding  a  feasible  system  architecture  is  possible,  but  making  radical  changes  in  the 
way  software  is  developed  is  not.  The  overall  system  architecture  must  be  designed 
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around  a  predictable,  reliable  battle  management  system  tha* cou^  J 
and  tested  using  existing  software  development  technology.  Any  other 
fundamental  research  problem  with  no  promising  Une  of  investigation  p  the  critical 

^  To  b.  specific,  the  panel  expects  no  technological  breakthrough  that  would 

mate  it  possible  to  write  the  celebrated  *10  million  lines  of  error-free  * 

W  the  successful  deployment  of  a  strategic  defense  system  on  a 

would  be  unrealistic.  It  will  be  important  to  develop  highly 

the  battle  management  system,  and  advanced  software  engineering 

heln  but  they  will  only  help  reduce  the  number  of  errors,  not  eliminate  them.  Th 

p^e\  ^enl  Stead',  the  pursuit  of  approaches  that  allow  the  system  to 

Lotion  dependably  despite  the  presence  of  some  errors.  Th«u 

be  reflected  in  the  overall  system  architecture  as  well  as  m  the  software  res 

SDIO  supports. 

Other  computing  technologies  have  more  “elasticity*  than  software.  For  ex- 
ample  the  computer  science  community  reasonably  expects  computing  hardware 
speeds’  to  increase  significantly.  SDIO  should  focus  attention  on  exploiting  advan 
that  are  likely  to  occur  and  on  exploiting  techniques  in  which  we  are  already  p 

h°w  to  h^iTiziu  ioft 

»  compUers,  database  management  systems,  and  version  control  systems*  Soft- 
ware  development  environments  would  certainly  be  enhanced  by  the  aval 
a  rich  set  of  these  well-understood  tools  and  significantly  faster  hardware^Jh 
enhancements  can  not,  however,  be  expected  to  make  the  impossi  p 

One  additional  note  of  warning  on  a  related  subject:  We  find  it  a  bit  trouble¬ 
some  to  be  discussing  whether  radical  advancements  in  software  techno 
enhance  the  quality  of  a  new  defense  system,  when  we  are  aware  that  y 
the  DoD’s  biggest  software  development  contractors  are  presently  literally  decade 
behiad  thc  suuof  the  art  -  an  art  that  is  only  a  few  decade  old.  Suppose  new 
technologies  do  come  into  being.  Are  we  sure  they  will  be  used. 

b.  Software  Research  Can  Not  Predict  Much 

Computer  Science  is  a  much  younger  discipline  than  physics,  whose 
are  much  more  thoroughly  understood.  No  one  suggests,  for  example,  solving 

difficult  power-generation  problems  peculiar  to  deploymg  be**n  ^im^s^f  effective 
bv  orbiting  perpetual-motion  machines.  On  the  other  hand,  the  limits  of  effect  1 
computability,  although  well  understood,  do  not  place  strong  constraints  on  ^a^^ 
possible.  In  particular,  there  are  no  laws  or  formulae  that  can  ^urat  y  p 
success  or  failure  of  a  large  software  development.  Sooner  or  later,  SDIO 
to  judge  which  proposed  battle  management  system  architecture  is  mo 
This  decision  will  have  to  be,  at  least  in  part,  qualitative. 
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Predictions  of  the  feasibility  of  a  software  system  design  are  fairly 
only  if  the  predictor  has  experience  implementing  a  quite  3l“,lar 
consideration  motivates  the  panel's  recommendation  of  the  «P  ™ 

development  projects.  Software  developers  could  gain  insights  into  the  best ;  y 

to  partition  the  system  into  modules;  some  critical  problems  could  surface.  Proto- 
typing  does  not,  however,  provide  complete  understanding. 

Just  as  in  many  other  fields  of  engineering,  a  system  that  is  much  larger  than  its  . 
earlier  prototype  may  cause  an  entirely  new  set  of  development  problems  to  become 
dominant.  Even  with  the  extensive  simulations  of  the  prototypes  we  assu 
performed,  the  information  obtained  from  a  prototyping  project  about  the  feasibility 
of  a  deployable  version  will  be  approximate. 

The  inability  of  software  experts  to  back  up  their  judgements  of  the  feasibility 
of  implementing  highly  complex  systems  with  “hard  figures”  places  them  at  a  disad¬ 
vantage  in  establishing  optimal  tradeoffs  between  system  complexity  and  hardware 
Qualitative  objections  to  some  software-intensive  ploy  to  save  hardware  costs  mi0ht 
be  overwhelmed  because  “hard”  dollar  figures  can  always  be  trotted  out  to  support 
the  “tricky”  approaches.  SDIO  should  adopt  a  policy  now,  despite  the  absence  of 
a  “one-line  proof”  of  its  necessity,  of  consistently  opting  for  the  simplest,  cleanes 

software  design  possible. 

c.  Software  Research  Can  Not  Evaluate  Much 

Given  that  SDIO  will  conduct  research  in  advanced  techniques  and  tools  for 
developing  software,  it  would  be  appropriate  to  have  a  way  of  measuring  their 
quality  and  their  applicability  to  the  development  of  a  battle  management  system. 
No  such  measurement  is  possible  today.  The  basic  reason  is  that  software  is  not,  in 
the  classical  sense,  an  experimental  discipline. 

This  is  not  to  say  that  software  engineering  is  not  an  experimental  discipline; 
it  is  indeed  such.  It  is  that  software  experiments  are  hot  designed  around  testa  e 
hypotheses,  as  in  the  classical  experimentalist  paradigm.  A  testable  hypothesis  is 
one  that  can  be  proved  or  disproved  by  the  result  of  a  properly  designed  experiment. 

Usually,  what  software  researchers  call  experimentation  is  the  construction  of 
prototypes.  There  is  rarely  a  hypothesis  being  tested  that  is  any  more  general  than 
“It  is  possible  (for  me  and  my  students)  to  build  a  small  system  with  property  x 
using  technique  y”.  This  constructive,  “existence  proof”  method  of  investigation  is 
prevalent  in  other  subfields  of  computer  science  as  well,  and  is  probably  adequate, 
whenever  the  primary  concern  is  with  design  issues- 

In  software  research,  however,  aspects  of  human  behavior  must  be  taken  into 
account.  Issues  of  how  humans  can  comprehend  notations,  express  computations  in 
them,  and  exchange  complex,  detailed  information  with  one  another  are  paramount. 
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The  lack  of  empirical  observation  of  human  behavior  in  an  experimental  setting 
therefore  limits  our  ability  to  measure  the  effectiveness  we  seek. 

I,  is  not  due  to  ignorance  or  negligence  that  software  research  rarely^ploys 

the  classical  experimental  paradigm.  It  is  simply *»« “S  require 
nractically  impossible  to  construct.  Large  software  develop  P  J 

35532^33=53? 

practically  impo^ible  to  control:  There  are  too  many  variables.  If  a  programmer  is 
^nccS-H  using  a  new  programming  language  to  implement  the  modu£  he* 
~dV;t  due  to  an  inherent  'inadequacy  in  the  language  the  hW>iV 

propriateness  for  that  type  of  application,  ***»»£ 
lamruaze,  or  his  inability  or  unwillingness  to  learn  it.  A  arge  v  , 

projects  might  aUow  such  local  variations  to  be  statistically  altered  out,  but  they 
Zldbe^en  more  expensive.  Thus,  assessments  of  software  development  tech- 
nioues  have  been  largely  qualitative.  Indeed,  many  of  the  well-known  papers  in 
p^a^InXguies  -d  orating  systems  discipiines  have  a  distinct  Savor  of 

literary  criticism. 

The  conclusion  is  simple:  for  most  of  the  software  research  issues  that  have  a 

rh _ _ component,  the  discipline  is  unequipped  to  supply  indisputabl 

m  nt^Uely  melurabl,  results.  This  differentiates  software  from  most  of 
the  other  scientific  aspects  of  the  Strategic  Defense  Initiative.  For  example,  if  one 
wants^to  decide  whether  free  electron  laser,  are  viable 

as  antimissile  weapons,  one  can  probably  construct  a  logically  s^“  d 

of  experiments  based  on  testable  hypotheses.  If  properly  designed  and  conducted 
Experiments  would  settle  the  issue  quantitatively  and  conclusively.  On  the 
otheHtand  if  one  wants  to  decide  which  software  development  technique  ,s  most 
appropriate  for  a  particular  subset  of  the  battle  management  software,  one  can  n 
o^ke  an  objective  assessment;  it  will  rely  at  least  partially  on  anecdotal  evidence 
and  the  subjective  judgment  of  experienced  people. 

B.  Recommendations 

The  panel  recommends  that  SDIO. 

.  Support  a  few  prototyping  project,  for  the  development  battle  management 
systems,  with  emphasis  on  the  methods  used,  such  that  these  efforts 1  £ 

developed  into  full  scale  deployable  systems.  These  prototypes  must  exh  d<‘  «he 
properties  important  for  the  strategic  defense  system,  such  as 
robustness,  network  based,  testability,  and  design  for  diversity  and  for  evolution. 
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•  Manage  the  above  battle  management  prototyping  and  the  architecture  projects 
such  that  they  can  influence  each  other. 


•  Support  research  in  software  technology  in  the  directions  that  are  expected  to 
influence  and  improve  the  development  of  the  software  for  the  strategic  defense 
system.  Section  A.2  of  this  chapter  has  a  list  of  such  topics.  SDIO  should 
manage  these  projects  to  assure  their  influence  on  the  software  deveiopmen 


efforts. 


•  SDIO  should  not  select  a  particular  software  method  (or  stylej  as  an  exclusive 
method  for  strategic  defense  software  development. 


C.  Summary 

The  feasibility  of  the  battle  management  software  and  the  ability  to  test,  simu¬ 
late,  and  modify  the  system  are  very  sensitive  to  the  choice  of  system  architecture. 
In  particular,  the  feasibility  of  the  battle  management  system  software  is  much  more 
sensitive  to  the  system  architecture  than  it  is  to  the  choice  of  software  engineering 


technique. 

Software  technology  is  developing  against  what  appears  today  to  be  relatively 
inflexible  limits  in  the  complexity  of  systems.  The  tradeoffs  necessary  to  make  the 
software  tractable  are  in  the  system  architecture. 

The  panel  does  not  recommend  that  SDIO  choose  a  particular  software  devel¬ 
opment  method  and  declare  it  to  be  the  preferred  or  exclusive  approach.  Instead 
the  panel  recommends  that  SDIO  support  several  diverse  battle  management  sys¬ 
tem  prototyping  projects  that  will  illuminate  the  specific  software  issues,  and  would 
contribute  to  the  specification  of  the  deployable  software. 

In  addition,  the  panel  recommends  that  SDIO  sponsor  research  in  software 
technology  along  directions  that  have  potential  to  benefit  the  battle  management 
system  development. 
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VI.  HARDWARE 


Unlike  software  technology,  where  there  appear,  to  be  little  growth 
th-  nanel’s  expectation  for  hardware  technology  is  one  of  continued  rapid  progr  . 

iXil  device,  and  in  architecture,  are  leading  to  system*  » 
increased  computing  speed  is  combined  with  reduction  in  sue,  weight,  and  power^ 
progress  a  a  result  of  ongoing  commercial  and  government-sponsored  effort, 
such  l  the  Very  High  Speed  Integrated  Circuit,  (VBSIC)  program  of  DoD  and 
VLSI  and  the  Strategic  Computing  programs  of  DARrA. 

This  report,  unlike  the  Fletcher  Report,  implicitly  assume,  that  spaceborne 
computing  power  will  be  plentiful.  It  is  important  to  make  this  assumption  a 

reality.  ... 

SDIO  should  exploit  advanced  computer  technologies  to  simplify  the  ““'  dif¬ 
ficult  task,.  The  architect,  and  system  implements!,  should  ask  thenude  h^ 
they  can  use  high-speed  computation  to  simplify  a  task,  rather  th 
„ performed  with  minimal  computing  capabiUties.  Initial  review  o  Phase  I 
architectures  revealed  a  very  conservative  proposed  us.  of  computers  in  aU  areas. 

The  panel  recommends  extensive  use  of  computers  in  all  activities  related  to 
SDI  Sonfe  actions  are  needed  to  prepare  the  hardware  technology  before  ^ 
nMda  This  chapter  deals  with  specific  actions  necessary  to  better  exploit  the 
hardware  potential.  The  panel  recommends  investment,  that  will  advance  hardware 
technology  in  time  for  deployment  decisions. 

A.  Discussion 

SDI  will  employ  digital  computing  hardware  in  these  areas: 

.  Object  Computers:  These  are  space-  and  ground-based  computers  tb^Perfo"“ 
the  computing  functions  required  for  battle  management,  signal 
communication.  Although  signal  and  image  processing  may  be  °"*‘{ 

side  the  scope  of  the  SDI  BM/C»,  the  computer  requirements  for  SDI  mus 
be  addressed  separately  for  BM/CS  and  surveillance,  acquisition,  tracking, 
kill  assessment  (SATKA).  In  the  past,  designers  tried  to  be 
hardware  and  made  the  software  overly  complex  to  compensate  for  the  lack 
computer  power.  The  panel  recommend,  use  of  massive  computer  power 

simplify  other  tasks. 

.  Simulation  Computers:  These'  are  ground-based  systems  used 

battle  management  system  at  various  levels  of  abstraction,  from  g 
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ceptual-level  simulation  to  the  lower-level  detailed  simulation  and  testing.  A 
the  low  testing  level,  the  simulators  could  be  coupled  with  the  deployed  system 
to  perform  in-line  system  tests.  Early  concept-level  simulation  of  the  battle 
management  system  may  run  on  a  single  computer,  but  all  other  levels  will  re¬ 
quire  massive  amounts  of  computation  that  might  be  available  only  from  high  y 
concurrent  multiprocessor  systems  and  supercomputers.  Simulation  engines  ca¬ 
pable  of  executing  thousands,  of  scenarios  are  necessary.  These  simulations  mus 
operate  quickly  to  allow  the  designers,  experimenters,  and  testers  to  perform 
their  tasks  efficiently.  The  simulators  will  be  required  to  run  faster  than  the 
machines  they  simulate.  It  will  be  desirable  and  feasible  to  deliver  to  each  sim¬ 
ulation  center  computing  engines  that  perform  simulations  significantly  faster 
than  current  computers. 


•  Software  Development  Computers:  These  are  the  computers  used  for  the  de¬ 
velopment  of  the  battle  management  software.  The  panel  encourages  use  of 
the  best  available  computing  facilities  in  this  area.  In  Chapter  V  (Software)  of 
this  report,  the  panel  strongly  recommends  significantly  increased  use  of  com¬ 
puting  resources  to  increase  the  effectiveness  of  software  development.  Because 
different  groups  will  use  different  development  systems,  the  panel  recommends 
that  their  facilities  be  interconnected  (via  computer  communication  networks) 
to  encourage  and  facilitate  sharing.  The  current  procurement  practice  that  dis¬ 
courages  capital  investment  has  greatly  hampered  innovation  in  defense  system 
development.  This  situation  is  unacceptable  for  SDI  software  development  ac¬ 
tivities,  which  could  benefit  from  increased  availability  of  computing  resources. 

.  Hardware  Development  Facilities:  These  are  the  facilities  that  hardware  de¬ 
velopers  use  to  increase  their  effectiveness.  These  facilities  include  powerful 
integrated  tools  that  allow  design  and  verification  of  hardware,  which,  when 
fabricated,  will  quickly  qualify  for  use  in  SDI/ space  applications.  Recently,  the 
design  and  simulation  of  very  large  scale  integrated  circuits  (VLSI)  has  forced 
the  industry  to  use  larger  amounts  of  computational  power.  Experience  shows 
that  massive  use  of  computation  in  the  verification  and  validation  of  custom 
chip  designs  significantly  decreases  the  time  required  to  obtain  working  chips. 
Again,  discouragement  of  capital  investment  through  competitive  procurement 
policies  has  hindered  defense  system  designers.  In  some  industrial  organizations 
innovative  VLSI  designers  use  significantly  more  advanced  computers,  more  so¬ 
phisticated  tools,  and  more  computing  cycles  than  their  counterparts  designing 
for  the  U.S.  government.  Hardware  developers  should  be  linked  via  communi¬ 
cations  networks  to  encourage  sharing  of  information,  of  design  tools,  and  of 
the  expensive  resources  needed  to  support  design  and  verification. 
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1.  Technology  Insertion  Delays 

TT  ...  Cfatea  has  an  advantage  over  the  Soviet  Union  in  hardware  technol- 

ssfeSSSS: 

We  must  reverse  this  trend.  We  mus  .•  There  are  several 

these  delays  and  innovate  faster  methods  for  technology  insertion.  There a* severa 

primary  reasons  for  the  delay  in  technology  inaertion  for  space  apphcati  . 

.  The  long  delay  between  the  development  of  a  new  technology  and  its  availability 
to  end  users. 

.  The  sequential  nature  of  accelerated  life  (step  stress)  testing  for  qualification. 

.  The  serial  order  of  development  of  a  dependent  technology  after  a  supporting 
technology  has  fully  matured. 

.  The  lack  of  general  testing  and  space-qualification  methods,  especially  for  cir- 
cuits  with  large  numbers  of  internal  states. 

In  many  cases  new  technologies  have  been  more  reliable  and  affordable  but 
Ur.  momentum  of  the  qualification  procedures  has  favored  older  ‘^olog.es.  Th 
trasrc  project  had  to  take  great  initiative  to  accelerate  the  use  of  newer  VLSI 

technologies.  ,  . ,  , 

Better  understanding  of  the  space  environment  and  the  behavior  o 
space  is  now  available.  The  current  practice  of  consenratism  m  use  of  te  g 
.terns  from  an  overly  restrictive  qualification  process  that  is  based  on  lack  of  pr  p 
appreciation  for  the  behavior  of  hardware  under  space  environments,  and  a  time- 
consuming,  unautomated  inspection  and  tracking  procedure. 

An  infrastructure  to  allow  architects  and  designers  to  confidently  use  the  current 
technologies  should  be  developed  and  regularly  upgraded  with  new  knowledge, 
and  facilities. 

SDIO  should  develop  special  design  rules  such  that  parts  designed  accor  ing  to 
theifw^b,  easier  to  qualify  for  SDI/space  applications.  This  knowledge  can  be 
ctded  in  software  tools  and  then  used  by  hardware  designers.  Hardware  d“ 
using  these  tools  wfil  qualify  rapidly  for  SDt/spac.  applications.  T  y 

already  experienced  in  designing  VLSI  circuits  w.th  software  tools. .  The  ntncate 
design  rtoes  (based  on  the  observed  behavior  of  devices  built  according  to  identical 
m  ar.  coded  in  the  software  tools.  Circuits  designed  using  these  tools  have 
tvoically  performed  correctly  on  -first  silicon”.  Availability  of  an  infrastructure 
integrating  such  tools  will  help  the  innovative  designers  implement  their  designs 
directly  to  the  SDI/space^ualified  technology.  The  most  creative  designers  will 
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make  a  variety  of  technical  tradeoffs  to  accommodate  the  specific  constraints  The 
current  practice  of  reengineering  earlier  designs  (optimized  for  unrelated  design 
constraints)  without  creative  designers  is  not  acceptable  for  the  SDI  application. 
Innovative  designers,  who  are  rare,  must  find  it  interesting  to  design  for 

To  solve  the  problem  of  the  lag  in  technology  insertion,  it  will  be  necessary  to 
propagate  a  different  culture  of  system  development  that  will  exploit  the  emerging 
Insertion  of  technologies  requires  a  continuous  upgrading  of  methods 
consistent  with  new  techniques.  The  endless  demands  of  project  schedules,  the  lack 
of  capable  staff,  the  lack  of  capital  equipment,  the  “not-invented-here  syn  , 
the  conservatism  in  procurement  decisions,  and  bureaucracy  have  created  a  cul  ure 
that  resists  change  and  takes  only  naive  risks.  SDIO  must  create  a  new  culture  that 
fun  adapt  to  changes  more  effectively. 

As  part  of  such  a  culture,  new  technologies  and  their  design  methods  would 
be  separately  certified  and  qualified  for  space/SDI  applications.  After  that,  stmt- 
dard  cells  and  other  functional  building  blocks  should  be  designed,  <lual^ed’ 
made  available  to  the  designers.  The  design  methods  and  the  standard  cells  sho 
support  the  testing  requirements  of  space/SDI. 

In  addition,  new  approaches  to  space/SDI  qualification  should  be  developed^ 
This  includes  test  structures  for  ongoing  monitoring  of  environmental  effects  such 
as  radiation  and  other  wearout  mechanisms. 


For  other  hardware  areas  such  as  microprocessors,  several  supporting  activities 
in  progress  are  encouraged  by  DARPA,  the  VHSIC  program  office  the  commercial 
users,  and  others.  The  panel  prefers  building  on  the  results  of  other  research  an 
industrial  development  rather  than  duplicating  efforts.  ParaUel  efforts  m  re  a  e 
hardware  technologies  must  be  pursued  with  coordination  and  periodic  crossover. 


The  experience  gained  among  workers  in  the  DARPA-sponsored  projec  s  as 
clearly  demonstrated  the  value  of  sharing  technical  information  and  development 
tools.  Encouraging  reuse  of  technologies  developed  at  other  organizations  is  essential 
for  rapid  progress  and  best  results  per  hardware  research  dollar. 


SDIO  should  accelerate  the  insertion  of  new  technologies  to  the  space  environ¬ 
ment,  by  creating  the  needed  infrastructure,  and  by  taking  steps  to  accelerate  the 
space/SDI  qualification  process. 

The  dominant  cost  items  in  the  estimates  presented  to  the  panel  regarding  the 
price  of  a  deployed  strategic  defense  system  are  the  “hardware”  of  the  defense  system 
(such  as  satellites,  weapons,  and  sensors),  and  placing  that  hardware  m  orbit. 

Due  to  the  large  manufacturing  volume  of  the  SDI  system,  SDIO  must  support 
development  of  automated  manufacturing  aimed  at  lowering  the  manufacturing  cost 
of  the  space  defense  hardware  by  “mass  production*.  Automated  manufacturing  is 
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a  multidisciplinary  issue  involving  robotics,  materials  science,  and  manufacturing 
science  SDIO  should  seek  advice  in  this  area  from  the  center  of  accedence 
automated  manufacturing  research  at  the  National  Bureau  of  Standards  (NB  ). 

In  fact,  SDIO  should  examine  a  Jeep  approach  in  addition  to  the  traditional 
and  dominant  Rolls-Royce  approach  to  space  assets. 

2.  Computing  Speeds 

Computing  speeds  have  been  improved  already,  and  further  improvement  is 
expected^ independent  of  SDI.  However,  advancement  in  algorithmically  specialize 
processors  and  in  concurrent  computer  architectures  has  been  very  s  ow  ecause 
thTr^arch  nature  of  this  field  and  because  of  limited  intent 
size  and  power.  Until  now,  size  and  power  have  been  reduced  with  the  help  of 
smaller  geometry  of  VLSI  rather  than  of  newer  architectures.  Current  desig 
functions  such  Z  arithmetic  operations  to  build  larger  functions.  Researchers  must 
2SSU  higher-level  functions  as  primitives  to  build  advanced  systems  with  much 

greater  capabilities. 

SDIO  should  develop  higher-level  reusable  functions  that  are  fully  optimised  for 
the  highest  performance  while  using  the  least  amount  of  power  and  space. 

Signal  and  image  processing  systems  are  currently  designed  with  computir^ 
functions  such  as  arithmetic  operators.  Often,  these  functions  are  simplided  by  us¬ 
ing  Bxed-point  arithmetic  to  minimize  the  hardware  task  at  the  expense  of  «nsider- 
abte  system  and  software  complexity.  Higher-level  functions  must  be  optimised  and 
standardized.  A  factor  of  10,000  improvement  in  size,  power,  and  weight  thi  g 
the  use  of  algorithmically  specialized  processors  such  as  systolic  arrays  and  Fast 
Fourier  Worm  (FFT)  processors  has  been  demonstrated.  It  Is  also  imporimfr 
to  identify  and  develop  specialized,  non-numeric  functions  suitable  for  use  in  SDI. 
Specialised  processors,  instead  of  lower-level  primitives,  will  then  be  used  to  build 

systems. 

Use  of  algorithmically  specialized  processors  demands  the  development  of  het¬ 
erogeneous  computer  architectures.  These  new  architectures  will  be  designed  t 
cope  with  the  massive  computing  capabilities  of  these  new  component^  Some^ork 
m  this  area  has  been  sponsored  by  DARPA’s  Strategic  Computing  program  and  by 

°NR. 

To  take  advantage  of  the  emerging  parallel  processor  architectures it  i vill  be 
necessary  to  develop  components,  interfaces,  and  control  structures.  These  devel¬ 
opments  will  be  influenced  by  the  packaging  technology.  Therefore, 
packaging  for  lowest  power  and  weight  plus  the  fastest  speeds  must  be  a™labl* 
the  designers  and  architects.  It  is  a  common  practice  among  commercial  computer 
manufacturers  to  develop  packaging  technology  in  parallel  with  the  architecture. 


-53- 


SDIO  should  develop  packaging  technologies  for  SDI  and  set  goals  sufficiently 
in  advance  to  allow  architectural  innovations. 

3.  Reliability  and  Availability 

The  special  nature  of  SDI  dictates  that  computing  assets  will  have  to  be  op- 
erational  for  a  very  long  time  without  manual  intervention.  Due  to  the  Umi  ^ 
internet  in  this  ieeue,  eignificant  computers  that  can  operate  unattended  “v«al 
years  are  not  available  and  are  treated  as  an  exception.  For  comparison, the  Shut' 
tie  computers  are  designed  with  MTBF  of  1,000  hours  (about  a  month),  which  is 
two  orders  of  magnitude  less  than  what  is  needed  for  satellites  that  are  expec :  e 
to  be  operational  for  10  years.  Therefore,  the  panel  recommends  that  SDIO  direct 
efforts  in  the  direction  of  achieving  full-scale  computers  with  hardware  and  software 
capable  of  operating  without  manual  intervention  for  periods  such  as  10  years. 

SDIO  should  invest  in  hardware  technologies  to  substantially  increase  com¬ 
puting  speeds  at  the  lowest  cost  in  power  and  weight.  Algorithmically  specnsted 
processors  and  fault-tolerant  hardware  are  some  of  the  most  promising  technologies. 
The  need  for  long  operational  life  in  space  must  also  be  addressed. 

Faults  will  be  caused  both  by  random  hardware  and  software  failures  and  by 
deliberate  hostile  actions.  When  failures  occur,  and  recovery  is  not  »">***’ 
computing  capabUities  must  degrade  gracefully  and  not  collapse  completely.  Dis 
tributed-  computing  with  loosely  coupled  sets  of  tightly  coupled  multiprocessors  is 
an  emerging  technology  that  offers  graceful  degradation  under  fault.  It  is  now  pos- 
sible  to  install  excess  capacity  that  will  tolerate  loss  of  some  computing 
The  SDI  computer  architectures  must  utilize  this  technology.  Miniaturization  h 
significantly  increased  hardware  reliability  and  availability. 

Further  improvement  is  expected  in  this  area.  Traditionally,  commercial  semi¬ 
conductor  manufacturing  facilities  have  been  able  to  process  large  wafers  with  very 
low  defect  density.  In  mass-produced  commercial  circuits  high  yield  is  obtained 
through  use  of  automation  and  highly  stable  foundry  operation. 

Physical  presence  and  involvement  of  human  operators  and  unstable  processing 
conditions  cause  low  yield  and  erratic  results  from  unautomated  research  foundr^ 
that  have  frequent  changes  in  the  processing  parameters  The  VKICconUacto^ 
suffer  from  low  yield  because  of  lack  of  automation  and  lack  of  stable  foundry 

operation. 

SDIO  should  examine  the  creation  of  a  highly  automated  SDI  foundry  (as  part 
of  the  infrastructure)  that  will  produce  Space/SDI  qualified  parts  with  lg  yie 
and  quick  turnaround. 

SDIO  also  needs  to  develop  technologies  to  cope  with  nuclear  effects  on  space 
assets.  The  electromagnetic  pulse  (EMP)  phenomenon  is  readily  dealt  with  by 
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s.rs=ss2: 

system.  A  conservative  system  design  must  commit  * '“**  v^'  d  ,  d 
programs  to  nonvolatile  secondary  storage  systems.  SDIO  needs  to  develop 

^alify  the  technologies  for  storage 

^t'%JLlKAu«.tly,  so  restarts  must  be  fast  Certain  viul  information 
(e  l  time,  orbital  elements  for  restoring  communication,  and  parts  of  the 
queue)  will  have  to  be  stored  in  a  way  that  is  immune  from  these  upsets. 

The  availability  and  reiiability  requirements 
sitate  extensive  use  of  fault-tolerance  technology.  The  methods  of  fault-tolera 
at  low  functional  levels  using  clever  coding  have  b«n  of 

i*  ,  qn«,  VTT<;Tr  Phase  HI  projects  further  developed  these  concepts,  use  oi 

memory  designs  and  — 

through  software,  as  in  the  DARPA/RADC  Advanced  Onboard 
I  AOSP1  project.  The  SDI  demand  for  reliable  operation  can  be  well  serv  y  p- 
Sthe  curtent  practice  with  early  demonstrations  of  advanced,  fault-tolerant 

hardware  technology. 

Hardware  fault-tolerance  to  natural  hardware  failures  makes  it  difficult  to  pro- 
cam  the  computers  unless  adequate  consideration  is  given  to  the  programming 
aspects  of  fault-tolerant  architectures.  The  fault-tolerance  of  memory  sys  ems  is  a 
*Jod  example  of  a  design  that  frees  the  software  developer  from  the  mconvemenc 
of  explicit  actions.  Traditionally,  recovery  from  a  hardware  failure  (transient  errors 
in  particular)  has  been  very  difficult.  Typically,  recovery  methods  are  supenmpo 
Tt"m  after  it  is  designed,  which  causes  tim^onsuming,  rough  methods  of 
recoveryfrom  failures  in  data  processing  systems.  Interestingly,  in  SD 1/ space  ap- 
^cXnuX  -every  procees  will  no,  require  a  return  to  exactly  the  pre-fadure 

state.  .  , 

SDIO  should  address  the  fault-tolerance  and  recovery  issues  specific  to  SDI  and 

other  space  applications. 

B.  Recommendations 

The  panel  recommends  that  research  and  exploratory  development  be  p^ued 
in  the  areas  described  previously.  SDIO  should  discourage  duplication  of  efforts 
under  SDI  in  the  areas  well  served'  by  other  initiatives.  SDI  participants,  howeve  , 
musT be  encouraged  to  take  the  initiative  in  using  the  results  of  those  other  efforts 
The  proposed  infrastructure  will  help  the  participants  confidently  use  the  results  of 

current  research. 
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1.  Create  Infrastructure  for  Rapid  Technology  Insertion 

•  Study  and  define  the  real  SDI/space  qualification  requirements  and  codify  them 
into  design  rules  for  devices,  packages,  and  systems. 

•  Study  the  reasons  for  delays  in  the  qualification  process  and  define  new  stream¬ 
lined  methods  for  SDI/space  qualification,  including  design  rule  checkers  and 
automated  manufacturing  tracking. 

•  Provide  quick-turnaround  fabrication  facilities  similar  to  the  DARPA/MOSIS 
facility  using  processes  and  packages  that  are  SDI/space  qualified  and  are  in¬ 
cluded  in  the  design  rule  checks  for  SDI/space  qualification. 

•  Provide  an  integrated  hardware  design  tool  set  that  is  regularly  updated  with 
state-of-the-art  tools  from  industry  and  universities.  These  tools  should  in¬ 
clude  checkers  for  the  current  SDI/space  qualification  design  rules  to  guarantee 
qualified  parts  soon  after  fabrication. 

•  Develop  a  set  of  SDI-qualified  standard  cells  and  upgrade  them  as  technology 
progresses. 

•  Develop  SDI  oriented  packaging  technology  integrated  with  the  fabrication  tech¬ 
nology  discussed  earlier.  Availability  of  a  dense  and  well-cooled  package  for  use 
by  all  hardware  designers  is  necessary.  The  packaging  technology  will  include 
consideration  for  ease  of  future  upgrades. 


2.  Deliver  Fastest  Computing  Speeds 

•  Develop  appropriate  computer  architectures.  Architects  should  develop  archi¬ 
tectures  for  SDI  requirements  that  deliver  the  fastest  computing  speeds  while 
adhering  to  other  constraints  such  as  ease  of  enhancement  and  fault-tolerance. 
This  should  be  a  multiprocessor  architecture  that  permits  efficient  use  of  het¬ 
erogeneous  processors,  including  algorithmically  specialized  processors. 

•  Develop  algorithmically  specialized  processors.  These  algorithmically  special¬ 
ized  processors  are  necessary  to  gain  significant  advantage  in  computing  speeds. 

•  These  modules  will  be  reusable  and  will  allow  flexibility  for  use  within  a  re¬ 
stricted  domain  without  diluting  the  performance  advantages.  They  will  be 
designed  to  fit  into  the  heterogeneous  architecture  described  earlier. 

•  Develop  an  architecture  optimized  for  SDI  simulation  applications. 
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3.  Increase  Availability  and  Reliability 

.  Develop  technology  for  feat  recovery  from  major  upsets.  This  technology  for  fast 
-overt  wdladikess  the  question  of  retaining  information  in  a  robust  part  of 
thehardware ^Tan  withstand  sever,  upsets.  It  will  aiso  address  ,h.  quest, on 
rf  h,Tto  regain  operationai  capabUity  in  the  face  of  loss  of  components. 

.  Develop  methods  for  very  long  service  life  in  space.  These  methods  will  address 
die  advantages  of  error  correction  at  low  levels  (i.s.,  arithmetic  error  detect  on 
and  correction)  that  is  not  a  common  practice  at  this  tune.  ^ 

causes  and  types  of  failures  in  the  SDI/space  environment  must  be  integrated 

with  these  new  designs  from  the  beginning. 

C.  Summary 

Research  directed  at  hardware  technology  offers  the  potential  for 
•A  nro™,  To  support  space  applications,  the  panel  recommends  that  SDIO 
sZto^ch  ^^  development  to  create  the  infrastructure  for  rapid  technology 
insertion,  deliver  the  fastest  computing  speeds  for  SDI  requirements,  an  increase 
hardware  availability  and  reliability. 
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VII.  COMMUNICATION 


A  strategic  defense  system  requires  secure,  survivable,  high-performance  com¬ 
munications  among  all  the  spaceborne  and  ground-based  assets. 

Due  to  the  specialized  nature  and  spatial  distribution  of  the  strategic  defense 
assets,  several  forms  of  coordination  {e.g.,  sensor  data,  advanced  warnings,  and 
handoffs)  are  required.  The  communication  must  be  robust  and  able  to  cope  with 
(innocent)  failures,  (malicious)  losses,  and  a  hostile  nuclear  environment  (. e.g .,  EMP 
and  neutron  flux).  It  must  also  resist  jamming  and  spoofing.  The  communication 
performance  requirements  are  anticipated  to  be  1-10  Mbit/sec  with  less  than  a 
few  tens  of  milliseconds  delay  among  closely  coupled  (neighboring)  assets  and  tess 
than  a  second  or  two  delay  between  any  remote  parties.  The  precise  performance 
requirements  depend  highly  on  the  system  architecture;  therefore,  they  are  not  well 
characterized  at  this  time. 

Th.e  requirement  for  high  bandwidth  implies  the  use  of  high  frequencies  lim¬ 
ited  to  line-of-sight  connectivity.  The  relative  motion  of  the  assets  (relative  to  each 
other  and  to  the  ground)  rearranges  the  physical  grouping  of  the  various  platforms. 
Some  of  the  communication  assets  may  not  be  operational.  The  logical  configura¬ 
tion  of  assets  into  battle  groups  must  then  occur  dynamically.  The  motion  causes 
the  line-of-sight  communication  connectivity  to  change  constantly.  Therefore,  the 
communication  network  must  be  able  to  rearrange  its  topology  dynamically.  This 
.requirement  implies  the  use  of  a  communications  network,  because  direct  com¬ 
munications  links  will  not  always  exist  between  every  pair  of  assets  that  have  to 
communicate  [e.g.,  between  the  boost  phase  detectors  and  the  man-machine  inter¬ 
face)  . 

It  is  most  likely  that  this  network  would  be  a  store-and-forward  type.  However, 
in  “local  areas”  {e.g.,  within  the  line-of-sight  domain  of  a  battle  group)  there  may 
be  additional  types  of  communication. 

The  communication  network  must  have  protection  against  enemy  countermea¬ 
sures  such  as  jamming,  spoofing,  and  destruction.  Techniques  for  ECCM  are  re¬ 
quired,  as  are  methods  of  monitoring  threats  to  the  network  (and  its  assets),  as¬ 
sessing  the  threats,  and  responding  appropriately  {e.g.-,  retracting  antennas).  When 
the  protection  mechanisms  fail,  the  network  must  exhibit  graceful  degradation  of 
its  performance  and  initiate  automatic  recovery  procedures. 

The  entire  communications  network  must  also  be  protected  from  itself.  For 
instance,  it  should  operate  in  spite  of  problems  such  as  its  assets  (nodes)  transmit- 
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.  j  i.  a  a^A\<n<r  flip  network  transmission  of  erroneous  information 
tin<r  excessive  data  and  flooding  tne  networx,  f 

operation,  load  dancing,  and  graceful  degradation  under  heavy  traffic. 

The  algorithms  for  operating  such  a  network  require  substantial  research,  de- 
velopment,  and  validation. 

SDIO  should  pursue  the  necessary  research  and  development  to  support  this 
type  of  dynamically  configured  communication  network. 

A.  Discussion 

1.  Dedicated  Communication  Network 

Volume  V  of  the  Fletcher  Report  implies  that  the  communkatio^network  be 

composed  only  of  the  strategic  defense  system’s  own  assets.  There  am,  howe  , 
several  other  possible  architectures  for  the  communication  system.  For  example, 
the  communication  may  be  structured  around  a  backbone, 
many  satellites  dedicated  solely,  or  mostly,  to  message  processing  mi 1  pas  ing  (  • 
switching).  This  concept  is  similar  to  DARPA's 

System  (MSS).  Such  a  scheme  can  support  a  variety  of  tradeo  , 

onmidirectionality  and  unidirectionality  of  transmission,  power, '  e^mat”e 

This  dedicated  communication  backbone  is  a  promismg  example  of  the  altemati 
communication  architectures  that  SDIO  should  explore. 

The  refative  simplicity  of  satellites  dedicated  solely  to  communication  results  in 
low  cost  Therefore,  SDIO  could  afford  to  acquire  enough  satellites  to  achieve  ear  y 
dense  coverage  and  redundancy.  Such  a  dedicated  communication  network  could  be 
built  and  deployed  as  a  few  independent  subnetworks  (possibly  by  different  vendors) 
that  cooperated  a  way  that  provide,  robustness  and  redundancy  through  diversity. 

One  of  the  main  features  of  the  separate  communication  system  concept  is 
achieving  in  early  deployment  a  complete  communication  coverage  to  support  the 
r^TdeXmcnt  of  the  more  expensive  strategic  defense  assets.  The  syriem 
orovides  coverage  in  an  innocuous  manner  without  violating  existing  s  ra  egic 

Separating  the  communication,  system ^m -re  ^pensive 
assets  allows  communications  improvements  independent  of  mod.ffcat.ons 
more  expensive  sensors  and  weapons. 

Therefore,  SDIO  should  study  various  communication  architectures  beyond 
what  is  implied  by  Volume  V  of  the  Fletcher  Report. 

In  particular,  SDIO  should  evaluate  the  concept  °f  \ded^^ed  c0r^ni^^ 
network.  If  the  evaluation  shows  promise,  a  prototype  should  be  designed,  imp 
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mented,  and  deployed  for  final  evaluation.  The  emphasis  should  be  placed  on  low 
cost  via  mass  production  and  deployment  techniques. 

2.  Network  Control 

The  behavior  of  any  large  dynamic  network  can  not  be  fully  predicted  analyti¬ 
cally  or  by  simulations.  Therefore,  it  is  necessary  to  have  the  ability  to  monitor  and 
control  the  entire  network’s  behavior,  including  performance,  connectivity,  activity 

levels,  and  blockages. 

Developing  a  man-machine  interface  to  visualize  the  network’s  dynamic  status  is 
necessary  to  allow  human  operators  to  recognize  and  detect  unpredicted,  undesired 
patterns  and  to  initiate  corrective  actions. 

Simulation  affords  an  objective  method  of  evaluating  alternatives.  This  method, 
which  is  necessary  due  to  the  complexity  of  the  communication  system  and  by  the 
interaction  among  its  components,  allows  the  study  of  various  system  and  deploy¬ 
ment  options.  A  communication  system  simulator  should  be  designed  such  that  the 
battle  management  simulators  (see  Chapter  IV)  can  incorporate  it  as  a  part  of  total 
system  simulation. 

After  system  validation  by  simulations,  there  would  be  a  need  for  more  detailed 
prototyping.  This  may  be  accomplished  by  a  system  consisting  of  a  small  number 
of  satellites  using  early  models  of  the  final  communication  system  (*.«.,  hardware, 
software,  and  algorithms).  • 

SDIO  should  develop  early  such  a  spaceborne  prototype  network. 

3.  Communication  Protocols 

The  importance  of  a  unified  set  of  consistent,  compatible  protocols  can  not 
be  overstated.  SDIO  should  take  advantage  of  the  substantial  body  of  existing 
experience  in  this  domain. 

The  system’s  ability  to  deliver  information  (as  opposed  to  bits  and  data)  de¬ 
pends  mainly  on  the  protocols  used.  The  protocol  suite  should  be  designed  to  be 
open  and  extensible.  It  should  be  compatible  with  other  software  interprocess  com¬ 
munication  (IPC)  procedures,  simulation  conventions,  and  other  internetworking 
requirements.  The  earlier  a  commitment  is  made  to  a  protocol  scheme  the  eas¬ 
ier  it  will  be  to  achieve  the  desired  interoperability  among  distributed  software, 
simulations,  and  internetworking  with  other  computer  communication  networks. 

Protocols  are  the  fundamental  means  to  facilitate  IPC.  They  act  as  the  “lan¬ 
guage”  that  processes  use  to  “program”  other  processes  to  perform  certain  tasks.  A 
properly  designed  set  of  protocols  could  handle  various  IPCs  in  a  consistent  manner, 
independent  of  the  spatial  distribution  of  the  processes.  They  should  handle  all  the 
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communication  detail,,  including  routing,  error  handling,  and  Bow  control,  without 
requiring  user  participation  (unless  so  desired). 

The  protocols  to  be  used  over  the  spacebome  communication  network  shoul 
be  developed  as  extensions  of  the  IPC  procedures,  with  spectal  attention  paid  jo  th 
unique  networking  requirements  of  the  strategic  defense  system,  su 
traffic,  type  of  service,  and  priorities.  These  protocols  should  also  be  compafble 

with  the  general  DoD  internetworking  protocols. 

There  are  several  aspects  in  which  the  SDI  protocols  differ  from  most  conven- 
tional^M* traditional  protocols,  such  as  those  used  in  other  DoD  packet  sw„chmg 
networks  («.».,  ARPAnet  and  MILnet).  The  SDI  protocols  must  deal  with ^requ 
meats  for  both  high  reliability  (such  as  for  weapon  release)  and  risofm  ma  -t 
sensor  communication,  which  has  totally  different  charactenstics.  The  SDI  pro¬ 
tocols  must  also  be  able  to  cope  with  signiffcant  variance  m  communication  per¬ 
formance,  such  as  those  caused  by  hostilities,  because  this  will  occur  when  hig 
performance  is  needed  most. 

The  interoperation  between  the  strategic  defense  “‘workandother  DoDnet- 
works  should  be  addressed  early.  Plans  for  interneting  shou  d  be  studied  e  pec  ?,  y 
with  other  DoD  spaceborne  networks,  for  providing  mutual  backup  capabilities. 

The  adapted  communication  protocols  will  affect  the  architecture,  software,  and 
simulation  methods. 

SDIO  should  address  early  the  development  of  protocols  oriented  toward  th6 
special  requirements  of  strategic  defense. 

4.  Technology 

The  existing  communication  technology  can  not  support  the  special  require¬ 
ments  of  the  envisioned  strategic  defense  system. 

There  is  already  a  dangerous  disparity  between  the  data  rates  avail*ble  ** 
point-to-point  communication  and  the  performance  of  store-and-forward  packe  p 
cessing  nodes.  The  data  rate  of  existing  packet  switches  and  network  managemen 
algorithms  is  lagging  behind  the  transmission  technology,  and  must  be  improve  . 

Survivable  networking  of  satellites  is  still  an  open  research  issue.  The  difficulties 
are  due  to  the  dynamic  configuration  required  by  the  changing  topo  ogy  caus 
the  difference  of  velocities  and  orbits, 

Both  power  and  security  considerations  suggest  the  use  of  ^ 
narrow-beam  communication.  Narrow-beam  communication  necessitates  exact  spa¬ 
tial  and  temporal  coordination  between  all  communicating  assets,  which  n^ay  ? 
possible  («.<?  ,  because  assets  can  not  generally  predict  when  others  need  to  initiate 
a  transmission  to  them).  To  overcome  this  difficulty,  an  omnidirectional  means  o 
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initiate  communication  ia  preferred,  followed  by  unidirectional  transmission  (e.y., 
beam  forming  and  retrodirectional  transmission). 


The  transmission  technology  requires  more  research  and  development  in  order 


to: 


•  Increase  the  communication  and  packet  processing  data  rates. 


.  Explore  advanced  transmission  media  (e.j.,  lasers  and  integrated  microwave 
devices). 

.  Improve  robustness  and  resistance  to  electronic  countermeasures  (ECM). 


•  Reduce  detection  probability. 

•  Develop  adaptive  error-correction/ data-rate  tradeoff. 


•  Improve  security. 


5.  Security 

The  security  requirements  of  the  strategic  defense  system  are  more  severe  than 
those  of  other  systems  because  of  it,  operational  characteristics  and  .its  unique 
nature  as  an  unattended  system.  The  security  of  transmission,  (TRANSEC)  and 
communication,  (COMSEC)  for  unattended  spaceborne  systems  is  much  more  com¬ 
plex  than  for  traditional  systems.  Special  attention  must  be  paid  to  issues  such  as 
external  override  and  reload  capabilities,  key  distribution,  and  access  control.  New 
approaches  to  the  security  of  computer  communication  must  be  developed  an  1 

plemented. 

The  panel  concludes  that  existing  security  systems  (concepts,  procedures,  and 
devices)  are  not  suitable  for  strategic  defense  and  that  new  systems  must  be  devel- 
oped  and  produced. 

SDIO  must  pay  attention  early  to  the  development  and  production  of  the  re¬ 
quired  security  systems.  This  is  expected  to  be.a  long  process  even  with  the  help 
of  the  National  Security  Agency. 


6.  SDInet 

•The  ARPAnet  is  a  successful  computer  network  that  supports  ^ource  sharing 
and  exchange  of  information.  SDIO  should  learn  from  the  success  of  the  ARP  ne 
and  establish  a  computer  communication  network  to  facilitate  cooperation,  infor¬ 
mation  exchange,  and  resource  sharing  among  the  SDI  contractors. 
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and  access  to  supercomputers. 

This  SDInet  should  also  support  intercomputer  ** t^aratoai 

oriented  levels,  such  as  support  of  electronic  mad, M  at  the  packet 
connections,  in  addition  to  tradition4  °^'  ®VgDI0  h  ld  pr0vide  its  contractors 

services.  , 

SDInet  will  serve  an  an  early  testbed  for  experiments  in  distributed  systems  that 

are  basically  similar  to  a  distributed  ^at«»c  tos,  astern,  ^  „  th, 

management  and  spacebome  communication  syste  . 
proving  grounds  for  the  SDI  protocol  development. 

An  important  payoff  of  such  a  network  is  the  formation  of  a  technical  community 
andUs  3«ant  deration.  The  benefits are To th  “c« 

the  SDInet  will  save  not  only  funds,  but  also  many  months  of  project  d  y. 

SDInet  will  help  contractors  to  cooperate  in  many  ways,  formally  or  informally, 
such^ytolgnew  software  on  simuWor,  located  at  other  teSDM 

—  i  ™  = “  -p 

ware  and  to  access  various  simulators,  it  win  Pruv 
through  its  gateways  to  MILnet  and  ARPAnet. 

will  also  alleviate  many  of  the  time-consuming  management  chores  sue 
as  vario^  demonstrations,  coordination,  submission  of  reports,  and  contract  update 

negotiations.  .  . , 

SDInet  should  be  built  to  carry  non-clsssiffed  information.  However,  it  should 
be  able  also  to  carry  “black"  classified  information. 

B.  Recommendations 

The  panel  recommends  that  SDIOt 

•  Initiate  a  study  of  communications  architectures  beyond  those  implied  by  Vol- 
MieV* of  the  Fletcher  Report,  hi  particular,  evaluate  the  concept £  s ^dedmaud 
communication  network.  If  this  evaluation  shows  protmse, a  ^ 

totype  network  should  be  designed,  implemented,  and  deployed  f»r  fi”al  e™ 
uattan.  The  emphasis  should  be  placed  on  low  cost  v,a  mass  production  and 

deployment  options. 
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.  Pursue  research  and  development  of  the  algorithms  and  protocols  for  operating 
the  recommended  store-and-forward  communications  network.  SDIO  should 
address  the  development  of  protocols  as  early  as  possible. 


•  Pursue  research  and  development  for  advancing  the  communication  technology 
toward  the  special  requirements  of  the  envisioned  strategic  defense  system.  Pay 
attention  early  to  development  of  new  security  systems. 


•  Develop  simulation  of  the  spaceborne  communication  networks  to  study  system 
and  deployment  options. 

•  Establish  a  computer  communication  network  (SDInet)  to  facilitate  cooperation 
and  information  exchange  among  SDIO  contractors. 


C.  Summary  * 

Research  and  development  are  required  for  general  communications  architec¬ 
tures,  for  spaceborne  networking,  for  SDI-oriented  protocols,  and  for  advancing  the 
spaceborne  transmission  technology.  The  entire  security  issue  requires  special  early 
attention  because  this  is  expected  to  be  a  very  long  process. 

The  concept  of  a  dedicated  spaceborne  communications  network  should  be  in¬ 
vestigated. 

•  SDIO  should  install  a  computer  communications  network  to  improve  cooper¬ 
ation  among  its  various  contractors,  and  to  serve  also  as  a  testing  groun  or 
distributed  system  architecture. 


VTTT.  program  management 


It  is  clear  oven  the  scope  of  the  technology  areas  that  require  investigation, 
that  the  BM/C*  technology  program  presents  SDIO  with  a  large  and  complex  man- 
“t  pfobL“^grL  requires  technical  direction,  progress  review  and 

evaluation,  and  effective  program  management  and  contractmg  practices. 

A.  Discussion 
1.  Technical  Direction 

To  provide  technical  direction,  SDIO  must  review  research  plans  “d'e'raluate 
sDeclac  approaches  and  proposals.  This  aspect  of  research  program  management 
requires  a  thorough  undJratanding  of  the  interdependence  of  research  efforts  under 
indirection.  This  interdependence  includes,  for  example,  knowing  when  one |  effort 
needs  the  results  of  another  and  understanding  how  a  delay  or  advance  tn  y 
particular  research  effort  affects  the  remainder  of  the  technology  program. 

This  aspect  of  research  program  management  also  includes  the  for«iff itc .ere- 
ate  the  technical  infrastructures  that  would  be  necessary  later  for  communication 
and  access  to  advanced  fabrication  facilities. 

SDIO-SY  should  maintain  strength  in  computer  science  with'mit=pr0^“ 
management  staff  in  order  to  understand  computer  science  issues  “  lh'J 
to  BM/CJ  and  to  be  able  to  structure  its  program  to  address  relevant 

In  addition,  SDIO  should  retain  an  ongoing  panel  of  scientific  " to  provi£ 
help  in  specific  areas  of  computer  science  and  to  review  the  BM/C  t“hn0‘°sy 
program  This  advisory  panel  would  provide  SDIO  with  advice  concerning  its  overal 
technology  program,  review  plans  and  evaluate  approaches  and  proposals,  monitor 
esg  of  technology  and  system  development  efforts,  and  provide  mdependen 
IZT,  would  abo  be  able  to  provide  SDIO  with  a  valuable  Unit  to 

technology  and  research  efforts  at  universities  and  national  laboratories. 

The  development  of  the  SDInet,  as  recommended  in  Chapter  VIII  (Communication) 
wmlld  be  one  positive  step  to  encourage  the  development  of  a  common  tecta, cal 
infrastructure  between  SDI  contractors.  It  would  also  provide  a  r«°ur“- ‘  * 

mechanism  and  promote  the  creation  of  an  SDI  community  for  software  devel  p- 

ment. 
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2.  Program  Management 

SDIO  needs  to  review  and  evaluate  research  efforts  to  maintain  program  per¬ 
formance  and  provide  program  redirection  when  necessary.  Review  and  evalua  ion 
of  research  papers,  technical  reports,  and  test  results  may  provide  the  mform 
tion  needed  to  determine  how  best  to  proceed  with  each  element  of  the  technology 

program. 

The  panel  recommends' that  SDIO  use  independent  contractors  to  perform  the 
technical  functions  of  program  managers  in  those  areas  in  which  SDIO  can  not  enlist 
personnel  of  the  appropriate  technical  caliber.  This  use  of  contractors  would  allow 
SDIO  to  tap  the  talent  of  leading  researchers  in  the  scientific  community. 

These  external  experts  will  be  able  to  provide  SDIO  with  technical  expertise 
that  would  not  otherwise  be  available  within  its  organization. 

These  experts  should  be  independent  of  the  major  contractors  to  assure  that 
they  would  be  unbiased,  with  no  other  objective  than  to  develop  the  most  effective 
SDI  technology  and  systems  within  fiscal  and  political  constraints. 

In  addition,  SDIO  should  routinely  assign  to  each  contract  another  contract  to 
cross-check  it  and  to  validate  its  results  and  its  deliveries. 

3.  Contracting  Practices 

Because  this'is  a  research  and  technology  development  program,  one  can  expect 
the  research  emphasis  to  change  throughout  the  program’s  duration  m  r^ponse  t0 
the  results  of  specific  research  efforts.  It  is  essential,  therefore,  that  SDIO  have 
the  management  freedom  and  flexibility  needed  to  adapt  its  program  in  response 
both  to  technological  evolution  and  to  delays  in  technology  advances.  Program 
management  tools  and  contracting  practices  must  support  the  provision  of  th 
management  freedom  and  flexibility. 

The  program  directed  by  SDIO  must  adapt  to  a  rapidly  evolving  and  chang¬ 
ing  environment.  As  a  result,  SDIO  needs  a  program  management  structure  and 
contracting  method  that  allows  it  to  alter  and  adapt  its  program  as  rapidly  as 
technology  issues  are  resolved.  Automated  means  of  tracking  program  inter  epen- 
dencies  are  needed.  Special  contracting  methods  or  clauses  or  changes  in  specific 
DoD  program  management  guidelines  are  needed.  For  example: 

.  Computerized  contracting  procedures  to  facilitate  the  contracting  process  and 
reduce  procurement  delay  and  paper  flow. 

•  Contracting  practices  that  encourage  capitalization  for  both  hardware  and  soft¬ 
ware  development. 
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contracts. 

Therefore,  SDIO  should  sponsor  research  to  achieve  responsive  program  man 
agement  and  contracting  practices. 

B.  Recommendations 

The  panel  recommends  that  SDIO: 

.  Maintain  strength  in  computer  science  within  SDIO-SY,  and  retain  an  indepen- 
dent,  ongoing  scientific  advisory  panel. 

•  Contract  independent  technical  program  managers,  when  needed. 

.  Us.  a  computer  communication  network  to  encourage  the  development  of  a 
technical  community  of  the  SDI  contractors. 

•  Sponsor  research  in  program  management  and  contracting. 

C.  Summary 

Research  emphasis  in  the  BM/C’  technology  is  likely  to  change  in  response 
to  evolving  technological  capabilities.  Innovation  is  reqmred  to  assist  SDIO 
managing  this  complex  technology  program. 

In  particular,  SDIO  should  be  free  to  contract  independent  technical  experts  to 
providethe  required  expertise  for  program  management  and  contractor  performance 
evaluation  that  would  not  otherwise  be  available  within  SDIO. 

SDIO  should  sponsor  research  to  develop  program  management  and  contract- 
ing  practices  that  will  allow  SDIO  to  alter  and  adapt  its  programs  as  rapi  y 
technology  issues  are  resolved. 
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ANNEX  B:  ACRONYMS  LIST 


ARPAnet 

The  communications  network  of  DARPA 

BM/C* 

Battle  Management/Command,  Control,  and  Communication 

BMD 

Ballistic  Missile  Defense 

DARPA 

Defense  Advanced  Research  Project  Agency 

DEW 

Directed  Energy  Weapons 

DoD 

1 

Department  of  Defense 

ECCM 

Electronic  Counter  Countermeasures 

ECM 

Electronic  Countermeasures 

EMP 

Electromagnetic  Pulse 

IOC 

Initial  Operational  Capability 

IPC 

Inter-Process  Communication 

KEW 

Kinetic  Energy  Weapons 

MILnet 

An  operational  military  packet  switching  network 

MOR 

Military  Operational  Requirement 

MOSIS 

DARPA’s  MOS  Implementation  Service 

MSS 

Multi-Satellite  System 

MTBF 

Mean  Time  Between  Failures 

NTB 

The  National  Testbed  facility  of  SDIO 

ONR 

Office  of  Naval  Research 

PPBS 

Planning,  Programming,  and  Budgeting  System 
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RADC 


RV 

SATKA 

SDI 

SDIO 

SLBM 

VHSIC 

VLSI 


Rome  Air  Development  Center 
Reentry  Vehicle 

Surveillance,  Acquisition,  Tracking,  and  Kill  Assessment 

Strategic  Defense  Initiative 

Strategic  Defense  Initiative  Organization 

Submarine-Launched  Ballistic  Missile 

DoD’s  Very  High  Speed  Integrated  Circuits  program 

Very  Large  Scale  Integrated  circuits 
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